Offen Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTROPHE!

[L.Mechler]

Hallo zusammen,

das Thema würde genauso gut in das eazyAuction bzw. Wawi-Unterforum passen, ich habe mich für das Shop3-Forum entschieden da ich denke dass hier am schnellsten eine Lösung gefunden werden kann.
Es handelt sich dabei um ein oder mehrere Probleme in Bezug auf das Zusammenspiel zwischen WAWI, eA und Shop wodurch die Bestandspflege ab einer gewissen Artikelanzahl praktisch unmöglich wird.

Da das Problem relativ komplex ist, hoffe ich es hier dennoch verständlich erklären zu können.

Wir versenden bisher hauptsächlich per Dropshipping und verkaufen über eBay und Amazon. Der eigene Shop steht jedoch in den Starlöchern und innerhalb der nächsten 2 Monate werden wir auch über ausreichend Lagerkapazitäten verfügen um unseren Versand teilweise selbst abzuwickeln, Drop- Shipping wird jedoch ein fester Bestandteil bleiben.

Wir haben ein am Anfang bestehendes Problem bzgl. Drop-Shipping (siehe http://forum.jtl-software.de/verbes...nzuordnung-handling-versand-dropshipping.html) gelöst indem wir aus allen Artikeln Stücklisten gemacht haben. Dadurch konnten wir unseren kompletten Bestellablauf größtenteils automatisieren, anbei ein Beispielartikel zur Verdeutlichung unserer Datenbankstruktur:

Artikelnummer WAWI	Beschreibung
10000	Var.Kombi Vaterartikel
10000-0001	Var.Kombi Kindartikel (Stückliste, besteht aus 15000-0001 und 19001)
10000-0002	Var.Kombi Kindartikel (Stückliste, besteht aus 15000-0002 und 19001)
15000	Var.Kombi Vaterartikel (identisch zu Art.Nr. 10000)
15000-0001	Stücklistenkomponente Var.Kombi Kindartikel
15000-0002	Stücklistenkomponente Var.Kombi Kindartikel
19001	Position Handling/Versandkosten

Um unsere Bestände auf eBay und Amazon abbilden zu können haben wir folgende Einstellungen:

10000-0001 und 10000-0002:

• Lieferant ist dem Artikel zugeordnet (ohne weitere Einkaufsinformationen)
• Drop-Shipping möglich: "JA"
• Mit Lagerbestand arbeiten: "JA"
• Überverkäufe ermöglichen: "NEIN"

15000-0001 und 15000-0002:

• Lieferant ist dem Artikel zugeordnet (inkl. aller Einkaufsinformationen)
• Drop-Shipping möglich: "JA"
• Lagerbestand des Lieferanten dem eigenen Lagerbestand zuordnen: "JA"
• Mit Lagerbestand arbeiten: "JA"
• Überverkäufe ermöglichen: "NEIN"

19001:

• Lieferant ist dem Artikel zugeordnet (Dummyartikel, Handling/Versandkosten -> erscheint somit als separate Position auf der Drop-Shipping Bestellung)
• Drop-Shipping möglich: "JA"
• Mit Lagerbestand arbeiten: "NEIN"

(Lieferanten-)Bestände werden per Ameise auf Artikel 15000-0001 und 15000-0002 gebucht.

Somit sind die bei eBay/Amazon gelisteten Artikel 10000-0001 und 10000-0002 in der auf 15000-0001 und 15000-0002 gebuchten Menge verfügbar (19001 arbeitet ohne Bestand) und die automatische Bestandsanpassung inkl. "Menge zu eBay" bzw. "Menge zu Amazon" können genutzt werden. Wenn ein Artikel weder am eigenen Lager noch am Lager des Herstellers verfügbar ist wird das Angebot automatisch beendet, also alles wie es sein soll.

Das Problem bzw. die Probleme tauchen nun auf wenn das ganze im Shop abgebildet werden soll.

Da wir in Absehbarer Zeit aus unserem eigenen Lager versenden soll im Shop der korrekte Lieferstatus abgebildet werden, d.h.:

1. Wenn ein Artikel am eigenen Lager ist Lagerbestandsanzeige "Grün" - Lieferstatus des Artikels (beim Artikel hinterlegt) = Lieferzeit (z.b. "2 bis 5 Werktage") - funktioniert
2. Wenn der Artikel nicht am eigenen Lager ist aber am Lager des Lieferanten Lagerbestandsanzeige "Blau" - Lieferstatus ausgeblendet - Hinweis "Artikel muss bestellt werden - Lieferzeit X Tage (Lieferzeit des Lieferanten) ab Bestellung. Artikel soll weiterhin gekauft werden können! Versand erfolgt per Drop-Shipping. - funktioniert nicht
3. Wenn Artikel nicht am eigenen Lager und nicht am Lager des Herstellers Lagerbestandsanzeige "Rot" - Hinweis "Derzeit nicht verfügbar" - Artikel soll nicht gekauft werden können. - funktioniert

Rein logisch wäre es - da es sich bei 10000-0001 und 10000-0002 ja um Stücklisten handelt - alle Einstellungen und Bestände bei 15000-0001 und 15000-0002 vorzuhalten (siehe Einstellungen der Artikel 10000-0001 und 10000-0002, Reiter "Artikelstückliste". Dort heißt es: "Wichtig: Ist diese Option gesetzt werden alle Bestände des Artikels automatisch aus Komponenten ermittelt."

Nach einigen Tests habe ich jedoch herausgefunden dass:

• Um 2. (siehe oben) zu erreichen muss der Lieferantenbestand zusätzlich auch auf 10000-0001 bzw. 10000-0002 gebucht werden?! Das ist unlogisch, die Stückliste sollte die verfügbare Menge doch aus den Komponenten ziehen.
• Die Option "Lagerbestand des Lieferanten dem eigenen Lagerbestand zuordnen" muss deaktiviert werden - somit funktioniert die automatische Bestandsanpassung/Beenden von Angeboten bei eBay und Amazon nicht mehr wenn ein Artikel zwar nicht am eigenen Lager aber am Lager des Lieferanten ist wird der Artikel beendet?
• "Überverkäufe ermöglichen" muss bei 10000-0001 und 10000-0002 aktiviert werden damit der Artikel im Shop auch ohne eigenen Bestand gekauft werden kann (ist aber ausgegraut) - kann einmalig über "Vererben" der Lageroptionen des Vaterartikels gesetzt werden, ist aber spätestens beim nächsten Abgleich der Lieferantenbestände wieder deaktiviert.
• "Überverkäufe ermöglichen" kann zwar bei 15000-0001 und 15000-0002 aktiviert werden (wo es meiner Meinung nach richtig wäre), diese Einstellung greift aber nicht im Shop! Außerdem werden dadurch auch bei eBay/Amazon Überverkäufe möglich was natürlich nicht sein sollte! siehe Ebay-->Eazyauction Überverkäufe. ? Kundenfeedback für JTL

Ist das tatsächlich der Fall und reproduzierbar oder sehe ich den Wald vor lauter Bäumen nicht?
Ich denke nicht dass das seitens JTL schnell gelöst werden kann?

Mein momentaner Lösungsansatz ist eine Änderung des Templates um hier die Bedingungen bzw. den jeweiligen Status (eigenes Lager/Lager des Lieferanten etc.) aus der Datenbank bzw. den Variablen auszulesen (ist ja zwangsläufig in Form von Variablen abrufbar) und über If-Bedingungen im Template dann Lagerbestandanzeige, Lieferzeit, Artikel kaufbar oder nicht usw zu steuern.

 

[MichaelH]

AW: Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTRO

"Änderung des Templates"
Falls du dir was für die Lagerampel programmieren lässt, dann mach es flexibel und als Plugin - ich denke hier im Forum würden etliche interessiert sein an einer etwas intelligenteren Lagerampel/Lieferstatus, inklusive mir selber. Da gibt es zwar schon viele Vorschläge und Beiträge dazu, aber JTL schaltet bei diesem Thema auf stur bzw. hat taube Ohren.

 

[L.Mechler]

AW: Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTRO

Ich denke mit der Lagerampel wäre es nicht getan, Lieferzeit wird ja auch im Warenkorb und im Bestellabschluss angezeigt. Und der "In den Warenkorb"-Button müsste auch da sein wenn Lieferantenbestand vorhanden aber "Überverkäufe möglich:" nicht aktiviert ist.
Am liebsten wäre mir natürlich wenn es ohne Template-Änderungen, d.h. so wie "erwartet" funktionieren würde.

 

[Thomas Lisson]

AW: Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTRO

hi,

Wenn der Artikel nicht am eigenen Lager ist aber am Lager des Lieferanten Lagerbestandsanzeige "Blau" - Lieferstatus ausgeblendet - Hinweis "Artikel muss bestellt werden - Lieferzeit X Tage (Lieferzeit des Lieferanten) ab Bestellung. Artikel soll weiterhin gekauft werden können! Versand erfolgt per Drop-Shipping. - funktioniert nicht

Das funktioniert nicht, weil das bei dir ein komplexer Artikel ist. Bei Nicht-SL Artikeln schaut es wie folgt aus: 13 Zoll Notebook, 4.399,00 €

Das Problem ist, dass im Shop nicht zwangsläufig die Stücklistenkomponenten mit angeboten werden müssen. Denn nur diese enthalten die Informationen über die Lieferfähigkeiten der Lieferanten. Daher ist keine autom. Errechnung der Lieferzeit bei komplexen Artikeln nicht aktiv und es wird die beim Hautpartikel hinterlegte Lieferzeit herangezogen. Die Errechnung der Lieferzeit eines Artikels muss die Wawi übernehmen, nicht der Shop.

aber JTL schaltet bei diesem Thema auf stur bzw. hat taube Ohren.

Das stimmt nicht. Bislang haben wir in der Wawi keine Mechanismen in der Wawi integriert, diese Anforderungen zu erfüllen. Aber eine Sammlung von Ideen nur zu diesem Thema wäre vorteilhaft für uns.

 

[MichaelH]

AW: Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTRO

Das stimmt nicht. Bislang haben wir in der Wawi keine Mechanismen in der Wawi integriert, diese Anforderungen zu erfüllen. Aber eine Sammlung von Ideen nur zu diesem Thema wäre vorteilhaft für uns.

Hallo Thomas !

Die unzähligen Threads hier im Forum suche ich nicht heraus, denn es gibt sogar ein Kundenfeedback mit 50 Stimmen (wohl schon einige wieder entfernt, weil man ja nicht viele hat, ich muss mit meinen Stimmen auch Prioritäten setzen, weil man ansonsten schon gar nicht mehr mitstimmen könnte, auch dies ein schönes Konzept, in der Praxis aber sehr "gummig" bis verwaschen für euch als Informationsquelle - auch lässt die Wartung/Pflege sehr zu wünschen übrig).

Darin sind Lösungen, auch eine sehr einfache mit Umsetzungsbeispiel für die Programmierung von mir, enthalten. Für die WAWI ein KlitzeKleiner-Aufwand für den Shop auch nicht großartig, da ja modular programmiert.

Hier der Feedback: Lagerbestand und Lieferzeit ? Kundenfeedback für JTL
Das Feedback wurde aber geschlossen !!

Ich nenne das "taube Ohren" bzw. "stur", denn es ist ein ewiges Thema und ewiges Problem mit der Lagerampel UND Lieferstatus in Abhängigkeit von nur 1 Einstellung, vor allem auch für Leute wie mich mit 4.800 Produkten und ca. 50 Lieferanten und die kann man eben nicht nur über 1 Kamm scheren. Auch erhalte ich keine CSVs nach dem Motto 08/15 sondern muss fortlaufend bestellen und mein Lager optimieren und kann da nicht jedesmal alles anpassen.
Die Lösung/Erweiterung die im Frühling 2013 für den Shop kam, war ein Schlag ins Wasser, keine Ahnung wer das so wollte oder gedacht hat dass das irgendwas bringt.

Besten Dank für´s Lesen und guten Rutsch !

SG,
Michael

 

[Thomas Lisson]

AW: Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTRO

hi,

das ganze ist ein komplexeres Thema. Dein Vorschlag, das mit Modellen (= Lieferstatus der Artikel) abzubilden reicht hier nicht aus.
Das Problem ist, dass der Lieferstatus im Artiklel dann manuell gesetzt werden muss. Man setzt ihn sehr wahrscheinlich in Abhängigkeit vom Lieferanten, genauer gesagt von der Lieferdauer des Lieferanten.

Was ist aber, wenn der Artikel mehrere Lieferanten hat? Was passiert, wenn sich die Lieferdauer für den Artikel bei dem Lieferanten ändert? Dann muss man manuell den Lieferstatus des Artikels ändern. Wir wollen eine Lösung, die einmal korrekt eingestellt, für immer automatisch arbeitet.

Um größtmögliche Funktionalität zu bekommen, müsste im Artikel hinterlegt werden können:
Lagerampel rot: LB <= X [X = frei eintragbar] Lieferzeit: Y [Y frei eingebbar (mit globaler Lieferzeit vorausgefüllt) bzw. Auswahlfeld "Lieferzeit vom schnellsten Lieferanten", "Lieferzeit vom schnellsten Lieferanten + 1 Tag", "Lieferzeit vom schnellsten Lieferanten + 2 Tage", "Lieferzeit vom standard Lieferanten", "Lieferzeit vom standard Lieferanten + 1 Tag", "Lieferzeit vom standard Lieferanten + 2 Tage"].
Lagerampel gelb: LB >= Y [Y = frei eintragbar] Lieferzeit: Y [Y frei eingebbar (mit globaler Lieferzeit vorausgefüllt)]
Lagerampel grün: LB >= Z [Z = frei eintragbar] Lieferzeit: Y [Y frei eingebbar (mit globaler Lieferzeit vorausgefüllt)]
Dabei muss gelten: X < Y <= Z

Somit könnten wir die meisten Szenarien auf Artikelebene abbilden.

 

[MichaelH]

AW: Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTRO

Ja, klingt sehr gut !

"Aber" - lieber eine einfache Lösung die bald kommt, als eine die noch Monate braucht ... ... das war mal das Motto von JTL, einfache flotte Lösungen, die zwar nicht alles können, aber sehr viel. Hier erkenne ich eher eine eierlegendeWollMilchSau mit Wartezeit.

Ich bin ein wenig "vorsichtig", weil ich miterlebte wie lange die Korrekturen zur Stückliste benötigten, nur um das zu erfüllen, was bei allen anderen Artikeltypen schon funktionierte = 12 Monate.
Bestellvorschlag bei dem noch einfachste Sachen wie zusätzliche gewünschte Selektionen seit 12 Monaten unberücksichtigt bleiben (z.B. Kategorien oder Warengruppe).
Benutzer wie ich die sich auf WMS freuten, es aber nicht nutzen können, nun mit der 99780 Vorversion der Lagerführung zufrieden wären (besser so als das was wir heute ohne WMS haben), aber mit einer verwürgten Lagerpackliste arbeiten müssen, die nicht selektierbar ist und auch sonst fast nichts erfüllt, diese muss ich heute 4-5 x drucken, ca. 50 % der 50-80 Seiten in den Kübel schmeißen nur um sie den Leuten selektiv in die Hand drücken zu können, damit jeder weiß was er zu tun hat, farbliche Markierungen die ich anbringen muss etc. etc. bla bla.

Drum bin ich mit einfachen schlauen und flotten Lösungen eher zufrieden, als mit Wartezeit die sich auf Monate oder Jahre summiert.
Natürlich sehe ich die riesen Fortschritte für JTL und auch für viele andere Kunden die Geld bringen und uns so unseren Software-Lieferanten "finanzieren", doch die Kleinen bleiben schon etwas auf der Strecke. Um es vollständig zu machen, JTL WAWI ist heute schon so komplex, also ich könnte nicht mehr so einfach starten und loslegen wie anno dazumal. Ich hoffe die "kleinen" Kunden brechen euch nicht weg. Manch´Software-Schmiede hat sich verrannt in "Komplexität", die ihr dann das Genick gebrochen hat, weil der Aufwand und die Wartung extrem steigen. Da gibt es einen Standard-Spruch von mir aus alten Tagen: "Die Komplexität einer Software steigt so lange, bis sie die Fähigkeiten der Programmierer übersteigt".

Noch bin ich voller Vertrauen, dass ihr das alles schafft und ich 100% auf JTL setzen darf !

 

[Thomas Lisson]

AW: Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTRO

hi,

aber mit einer verwürgten Lagerpackliste arbeiten müssen, die nicht selektierbar ist und auch sonst fast nichts erfüllt

Die wird nicht mehr nötig sein, wenn die Wawi selbst Picklisten kann. Zusammen mit dem Packtisch vom WMS wird die Wawi im Versandprozess sehr gut von kleineren Händlern genutzt werden können.

= 12 Monate.

Mit der Vereinheitlichung von Programmkomponenten (Variablen im Formulareditor, Exporte, Emails, Sendungsdaten etc.) und den neuen Ausgabeprozessen haben wir viel unter der Haube neu machen müssen, um künfig effizienter und schneller zu sein. Das hat leider länger gedauert wie geplant. Aber die Zeit holen wir in den nächsten Monaten bereits wieder rein und sind sehr gut vorbereitet für neue Komponenten wie den Workflowmanager.

"Aber" - lieber eine einfache Lösung die bald kommt, als eine die noch Monate braucht

Das sehe ich in dem Fall anders. Es nützt uns nichts, das Problem im JTL- Shop zu lösen, bei eBay, Amazon und Drittshopsystemen aber nicht.

 

[MichaelH]

AW: Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTRO

"Das sehe ich in dem Fall anders. Es nützt uns nichts, das Problem im JTL- Shop zu lösen, bei eBay, Amazon und Drittshopsystemen aber nicht."

Die Lagerampel (und auch Lieferstatus) ist nun mal eine Funktion im Shop3 und nicht wo anders ... ich sehe z.B. auch keine Verbindung zwischen Lagerampel und Amazon und ob die Anpassung z.B. auf die Anzahl Tage für Amazon damit auch abgedeckt ist wage ich zu bezweifeln, für mich ist das nicht grad so 1:1 zu sehen.
Ich habe für Amazon andere Lieferdauer als im Shop, weil Amazon 1) weniger wichtig ist für mich und 2) ich mir damit ein Polster für Amazon verschaffe.

Du müsstest somit also in dein Konzept auch noch die Plattform aufnehmen, womit die Komplexität wiederum steigt, sofern du die Flexibilität erhalten/erreichen willst, wie beschrieben.

Weiters kommt dann ggf. noch einer und will die Kundengruppe mit drin haben (Händler werden anders bedient als Endkunden) oder auch "Multishop" (? - weil ich das selber nicht nutze).
Soll ich das Lieferland noch erwähnen ? Im Shop3 heißt es ja "Lieferzeit" und die wäre je nach Land auch nicht gleich (im Sinne der "eierlegenden WollMilchSau")

Liegt ein Teil der Logik also nicht im Shop3, wird´s wiederum komplexer.

Denkst du ihr schafft eine Lösung die all dies auf allen Plattformen abdeckt ?


"Die wird nicht mehr nötig sein, wenn die Wawi selbst Picklisten kann. Zusammen mit dem Packtisch vom WMS wird die Wawi im Versandprozess sehr gut von kleineren Händlern genutzt werden können."

Wir sind "Konfektionierer", d.h. es liegen kaum fertige Produkte am Lager (zudem ALLE ohne Barcode und den wird es auch nicht geben, weil ich dann die komplette Etikettierung umstellen müsste, Größe, Art des Drucks, Inhalt, also ein Unding) die werden an den entsprechenden Plätzen konfektioniert und sind dann erst "fertig", dazu ist Papier immer noch die bessere Grundlage als ein Bildschirm. D.h. wenn die Picklisten auf Papier existieren dann ist´s gut, wenn der Packtisch nur "Differenz-Bestätigung" erlaubt, dann ist es auch OK.
Also, Portables & Co. im Lager - ist nicht mein Ding, das Risiko von Ausfällen und lästigen Nebeneffekten ist gerade für einen Kleinbetrieb nicht von Vorteil. Auch wäre ich dann nicht verzichtbar, 1 Problem und alles steht, also das Gegenteil von dem was ich anstreben wollen würde.
Heute kann ich fast alles vorbereiten und dann werde ich für Stunden nicht mehr benötigt, Problemfälle kann ich blockweise lösen oder gar am nächsten Tag, da nach meiner Vorarbeit so gut wie alles über Papier läuft.

Ansonsten müsste ich schon über eine SQL-Lösung für die Lagerpackliste nachdenken und die ggf. programmieren lassen, denn in der derzeitigen Liste gibt es weder die Felder "Kategorie" noch "Warengruppe" noch sonst was das ich vernünftig verwenden könnte. Derzeit behelfe ich mich mit der UNNummer (die ich nicht benötige) in der ich mit CSV-Import mein Lager darstelle um wenigstens eine grobe Struktur zu haben.


Es gibt also vieles zum drüber nachdenken, wenn man die eierlegende WollMilchSau haben will. Nicht grad "trivial". Womit wir wieder beim Aufwand = Termin sind, während mein Vorschlag eben eine Shoplösung ist (dort wo es die Ampel eben gibt) und recht flott gemacht werden könnte.

Aber nun genug der Dinge, ihr werdet das schon brauchbar umsetzen.

 

[L.Mechler]

AW: Lagerbestände/Lieferantenbestände Var.Kombis/Stücklisten -> DropShipping KATASTRO

Hallo zusammen,

anbei mein "theoretischer" Lösungsansatz für o.g. Problem, das ganze muss ich jetzt nur noch umsetzen (wird eine kurze Nacht...)

Anregungen/Kritik/weitere Vorschläge sind natürlich jederzeit wilkommen!

Im Template sind die Variablen

• "$Artikel.fLieferzeit" = Lieferzeit des Lieferanten aus 10000-0001 (Var.Kombi Kindartikel [Stückliste, besteht aus 15000-0001 und 19001]), nur gesetzt wenn Lieferantenbestand >=1
• "$Artikel.fLagerbestand" = Lagerbestand komplett (eigener Bestand + Lieferantenbestand) aus 15001-0001 (Stücklistenkomponente Var.Kombi Kindartikel)
• "$Artikel.fLieferantenlagerbestand" = Lagerbestand des Lieferanten aus 10000-0001 (Var.Kombi Kindartikel [Stückliste, besteht aus 15000-0001 und 19001])

vorhanden.

D.H. dass ich, sofern ich den Lieferantenbestand von 10000-0001 und 15000-0001 synchron halte (Lieferantenbestand wird per CSV auf 15000-0001 gebucht) den eigenen Lagerbestand errechnen kann aus "$Artikel.fLagerbestand" abzgl. "$Artikel.fLieferantenlagerbestand".

Die Synchronisierung muss automatisiert per Ameise erfolgen:

Da bei einem Verkauf - sofern keine eigene Ware am Lager ist - der Lieferantenbestand von 15000-0001 verringert wird muss dieser regelmäßig per Aufgabenplanung mit der Ameise (CommandLine-Version) exportiert und anschließend als Lieferantenbestand von 10000-0001 importiert werden. Nach einem WebShop-Abgleich ( Worker) ist der Bestand im Shop aktualisiert.

Die oben errechnete Differenz wird einer eigenen Variable zugewiesen.

Mit Hilfe dieser Variable (errechneter eigener Lagerbestand) kann dann per {if} Anweisungen das Template entsprechend angepasst werden so dass der gewünschte Effekt aus dem ersten Beitrag entsteht.