Sync Priorität Lager und Bestand

[shetani]

Hallo Zusammen,

eine kleine Frage zum Verständnis.

WIe sieht die Synchronisationspriorität bei eS und OsC aus ?

Beispiel:

Artikelanlage, bzw. erste Bestandserfassung in eS

Lagerbestand eS und OsC nach sync

Variation 1 = 3 St
Variation 2 = 0 St
Variation 3 = 2 St
(Lager gesamt 5 St)


Nun kauft jemand in OsC 2 x Variation 1 und bestellt Variation 1 1 x vor
erneute Synchronisation müsste danach ergeben.

Lagerbestand eS und OsC nach sync

Variation 1 = 1 St
Variation 2 = -1 St
Variation 3 = 2 St

(Lager gesamt 5 St reserviert 3St)

Wenn nun jedoch der Artikel VOR sync manuell in eS geändert wird, z.B.
ein zusätzliches Bild eingefügt oder eine Textpassage angepasst wurde, will eS den Artikel ja an OsC senden.

Wenn ich jetzt wieder das obige Beispiel anziehe,
es kauft jemand in OsC 2 x Variation 1 und bestellt Variation 1 1 x vor, müsste bei der Sync doch folgendes Problem auftreten.

Bestand VOR Sync !
Bestand eS (Lager gesamt 5 St)

Variation 1 = 3 St
Variation 2 = 0 St
Variation 3 = 2 St

Bestand OsC (Lager gesamt 2 St)

Variation 1 = 1 St
Variation 2 = -1 St
Variation 3 = 2 St

Bestand NACH sync !
Bestand eS (Lager gesamt 5 St)

Variation 1 = 3 St
Variation 2 = 0 St
Variation 3 = 2 St

Bestand OsC (Lager gesamt 5 St)

Variation 1 = 3 St
Variation 2 = 0 St
Variation 3 = 2 St

und damit falsch, da die Bestände von eS, obwohl Sie nicht angefasst wurden, mit an den shop transferiert werden.

Theoretisch müsste es derart gestaltet sein, das wenn Lagerverwaltung in eS aktiv gestellt ist, die Bestandsdaten von eS
an OsC nicht automatisch übertragen werden, solange kein Wareneingang verbucht wurde.

Könnte entweder durch etwas kompliziertere Scripte laufen oder durch ein einfaches Auswahlfeld in de eS, welches zum
Beipiel atsnadardmässig auf Bestände (Lager und Variationen) nicht übertragen steht und nur dann deaktiviert ist, wenn
Bestände in der Wawi geändert wurden (zum Beispiel durch Wareneingang)

Sehe ich das richtig oder liegt hier ein massiver Denkfehler vor ?!

 

[Andreas Grambow]

Die Sync-Prio sieht so aus, das er zu erst sendet, und dann abholt. von daher hast du Recht, das er alles überschreiben würde,

wenn nicht => erst in der Wawi der "Status" reserviert gesetzt wird, da OSC meiner Meinung nach dies Standartmäßig nicht unterstützt. Sprich dieser Status kommt nicht vom Shop sondern ist Wawi intern.

Daher denke ich,das da nix passieren kann.

So habe ich das mit den Sync-Prio´s verstanden. nachstellen kann ich es selber zur Zeit nicht, da ich keine testWawi laufen habe.

Ich denke, da werden aber auch Thomas oder Janusch etwas zu sagen können

 

[shetani]

Hm, danke für die schnelle Antwort.

Bedeutet für mich, das ich nun erstmal das Bit für Top-Angebot ( da ich es im OsC nicht brauche) umfunktionieren werde und als Indikator für den Connector umsetze.

Nach dem Motto, wenn TOP-Angebot dann aktualisiere Bestände, ansonsten eben nicht

Mal sehen was Thoma und Janusch noch so von sich geben zu dem Thema

 

[Lars]

WIe sieht die Synchronisationspriorität bei eS und OsC aus ?

Beispiel:

Artikelanlage, bzw. erste Bestandserfassung in eS

Lagerbestand eS und OsC nach sync

Variation 1 = 3 St
Variation 2 = 0 St
Variation 3 = 2 St
(Lager gesamt 5 St)


Nun kauft jemand in OsC 2 x Variation 1 und bestellt Variation 1 1 x vor
erneute Synchronisation müsste danach ergeben.

Lagerbestand eS und OsC nach sync

Variation 1 = 1 St
Variation 2 = -1 St
Variation 3 = 2 St

(Lager gesamt 5 St reserviert 3St)

Richtig

Wenn nun jedoch der Artikel VOR sync manuell in eS geändert wird, z.B.
ein zusätzliches Bild eingefügt oder eine Textpassage angepasst wurde, will eS den Artikel ja an OsC senden.

Wenn ich jetzt wieder das obige Beispiel anziehe,
es kauft jemand in OsC 2 x Variation 1 und bestellt Variation 1 1 x vor, müsste bei der Sync doch folgendes Problem auftreten.

Bestand VOR Sync !
Bestand eS (Lager gesamt 5 St)

Variation 1 = 3 St
Variation 2 = 0 St
Variation 3 = 2 St

Bestand OsC (Lager gesamt 2 St)

Variation 1 = 1 St
Variation 2 = -1 St
Variation 3 = 2 St

Bestand NACH sync !
Bestand eS (Lager gesamt 5 St)

Variation 1 = 3 St
Variation 2 = 0 St
Variation 3 = 2 St

Bestand OsC (Lager gesamt 5 St)

Variation 1 = 3 St
Variation 2 = 0 St
Variation 3 = 2 St

Beim Sync wird die Bestellung in es erfasst und die Bestände werden wieder korregiert, somit müßtest du danach nochmal Synchronisieren, dann stimmt der Bestand auch in OSC.

Wobei es sowieso egal ist, da OSC standardmäßig gar keine Bestandsführung in Variationen führt.

Es sei den du hast das Contir QT Pro eingebaut, aber selbst dann müßte der Connector erst angepasst werden.

 

[shetani]

Hallo Heinzi,

noe, qtpro habe ich wieder untergeschmissen und mir meine eigene contrib gestrickt.

die kann jetzt sowohl Master products als auch Variationen darstellen und das ganze mit baseprice und bestandsverwaltung realisieren. (allerdings nur mit einer Variation)

Den Connector habe ich ebenfalls genau auf diese Situationen angepasst.

Kann sein das ich noch einen Denkfehler habe bzgl . der Bestellübernahme muss ich mal testen

 

[Lars]

Hallo Heinzi,

.

Kann sein das ich noch einen Denkfehler habe bzgl . der Bestellübernahme muss ich mal testen

Meiner Meinung nach wird der Bestand von OSC na ES gar nicht abgeglichen, sondern nur von ES nach OSC...

Ist das vielleicht der Denkfehler??

 

[shetani]

Ja das ist eben genau das Problemchen und der kleine Denkfehler an der Sache.

Bei den Variationen geht es ohne Probleme, doch müsste der Connector für zum Beispiel ein Masterproduct die Daten ebenfalls aus OsC beziehen.
UNd eben das macht es natürlich nicht.

Beispiel :

Master product führt den Bestand für 3 untergeordnete Produkte.
Wenn eines der untergeordneten Produkte erworben wird, dann wird nur der Bestand des untergeordeneten Produktes in WaWi übernommen und geändert, nicht jedoch das Master product. muss mal sehen wie ich das in den Griff bekomme. Wünschenswert wäre eine Option, die es ermöglicht angeschlossene Artikel durch ein Bit, z.B. MasterID, bei der Bestellübernahme zu kennzeichnen und dadurch Wawi zu veranlassen die Stückzahl bei dem Master Product nue zu berechnen.

 

[Lars]

Ich kenn das Contrib Master Produkt nicht.
Zumindestens nicht von der Funktionsweise.

Selber nutze ich entweder Variationen, bei ständig verfügbaren Artikeln
und bei vielen Variationen nutze "Artikelgröße 3.2.1" als Contrib.

Bei Artikelgröße ist es sicherlich ähnlich wie bei Masterprodukt.

Dort habe ich auch einen Masterartikel und die Größen werden als Slaveartikel einzeln angelegt, sowohl in der WAWI als auch im Shop.
Somit ist eine Bestandsführung möglich und der masterartikel hat 0 Bestand.

Wozu hat der Masterartikel denn bei dir Bestand?

 

[shetani]

Es ist keine offizielle Contrib sondern eine selbergestrickte.

Warum der Artikel Bestand hat ist recht einfach. Er spiegelt den Gesamtbestand der angeschlossenen Produkte wieder. Grund dafür ist, das wir die "Slaves" nicht als Variationen integrieren können da einige davon als Stück und andere wiederum als z.B. kg abgerechnet werden.

Die "Slaves" haben eigentlich keinen reelen Bestand sondern ziehen den aus dem Masterprodukt mit entsprechend hinterlegten Umrechnungen um somit die Verfügbarkeit darstellen zu können. Unsere Mädels müssen so quasi nur einen Artikel, nämlich den Master, Bestandsmässig pflegen.

Eventuell bau ich mir unsere Variationscontrib nochmal um um dem ganzen Herr zu werden. Scheue im Augenblick nur noch etwas den Aufwand. Mal sehen