Multishop - Was ist das für euch?

[webald]

Ticket #403, erstellt von Voodoopupp:

Er äußert darin den Wunsch einer "Multishopfähigkeit". Aber was genau beinhaltet das?

Ein Shop, mehrere Verkäufer? Typ Mini-A--zon?
Mehrere Shops, gleiche Artikel?
Unterschiedliche Beschreibungen?
Ein Kundenstamm?

Linkback: https://www.modified-shop.org/forum/index.php?topic=32582.0

[manne35]

Hallo,
die beste Umsetzung finde ich hat der hhg shop bei den fuer mich interessanten Systemen.
Und presta, allerdings speziell in Bezug auf Multishop ist m E der hhg shop am Besten.
Da kannst Du halt alles was Du schreibst anpassen oder einstellen.
Ist das ein Wunsch für modified ?

[voodoopupp]

Hi,

das Ticket ist ja von mir, deshalb auch ein paar Anregungen von mir, was für mich zu einem Multishop dazugehören würde. Grundsätzlich ist mein Gedanke an einen Multishop erstmal die gemeinsame Datenbasis-Pflege und Verwaltung.

Also quasi einen "Master" in dem man eigentlich alles pflegt, und mit ein paar Häkchen sagt:
Produkt A kommt in Shop E, Shop B und Shop F ....

Hier mal die wichtigsten Dinge:
- komplett eigenständige Domains / unabhängige Auftritte
- gemeinsamer abgleichender Lagerbestand
- Produkte, Kategorien, Hersteller, Contentseiten sind mehreren Shop zuordenbar
- gemeinsame oder getrennte Preisgestaltung
- getrennte Designgestaltung/Templates

Nice-To-Have:
- gemeinsame oder getrennte Konfigurationen (Versandmodule, Zahlungsarten, usw.)
- gemeinsamer oder getrennter Kundenstamm (Anmeldung in mehreren Shops möglich)
- gemeinsamer oder getrennter Produktbeschreibungen (evtl. dann doch manuell im Slave-Shop einzustellen!?)

Das ist hier jetzt keine vollständige Liste, sollte aber mal ne Idee liefern, was ICH mir unter Multishop vorstelle. Der Grundgedanke ist einfach, dass man ohne große Probleme gleiche Produkte in verschiedenen Shops anbieten kann und der Warenbestand in allen Shops aktuell gehalten wird. Und das ohne Umwege über WaWi o.ä. - denn das birgt immer Probleme mit dem Bestand durch Zeitverschiebungen im Abgleich, da ja nicht just in time abgeglichen wird, sondern meistens nur in bestimmten Intervallen.

Grüße
Dominik

[mr.mc.mauser]

Machbar wäre das....

Es müsste jedoch sehr sehr viel angepasst werden, was zu vielen Problemen führen könnte.
Die Entwicklungszeit würde die Entwicklungszeit von 2.0 bei weitem übersteigen.
Fast keins der jetzigen 'Module' würde mehr laufen.

Es wäre so sehe ich das zumindest, fast leichter ein neues System aufzubauen und nur einige Codeschnipsel vom jetzigen System zu übernehmen.

Obwohl es mich reizen würde sowas zu basteln, ich würde es nicht machen.

[xxxxxxxxx]

...
 Und das ohne Umwege über WaWi o.ä. - denn das birgt immer Probleme mit dem Bestand durch Zeitverschiebungen im Abgleich, da ja nicht just in time abgeglichen wird, sondern meistens nur in bestimmten Intervallen.

Wenn Du per cronjob diese Intervalle einrichtest, kannst Du die Abgleiche im Minutentakt laufen lassen.

Das Problem mit Niedrigbeständen hast Du auch im Multishop, wenn in unterschiedlichen Shops Kunden den gleichen Artikel in den Korb legen und der eine schneller auf dem Weg zur Kasse ist. Es sei denn, in diesem Multishop würde die Artikelbestände gebucht werden, wenn sie disponiert werden, sprich, sie jemand in den Korb legt. Aber das würde wieder andere Probleme bringen.

Ansonsten, die meisten Punkte Deiner Liste sind in anderen Systemen realisiert.

Nachtrag: Noch als Denkanregung > Es muß, wenn es nur um Artikel geht, nicht immer eine Wawi sein, die den Shop mit Artikeldaten (Beständen) füttert und abgleicht. Goggle mal PIM (Produktinfo Management).

[awids]

Ich halt mich schon seit gestern zurück, hierauf zu antworten, weil ich nicht weiß, ob es dann ein kommerzieller Link ist, aber Modified als Multishop wurde bereits als kostenpflichtiges Modul gelöst und erfüllt so ziemlich die Anforderungen, die oben gestellt wurden.

Einfach mal "Modified Multishop" bei Google eingeben.

[voodoopupp]

...Es müsste jedoch sehr sehr viel angepasst werden, was zu vielen Problemen führen könnte.
Die Entwicklungszeit würde die Entwicklungszeit von 2.0 bei weitem übersteigen.
Fast keins der jetzigen 'Module' würde mehr laufen....

Deswegen hab ich das ja als Wunsch/Anregung für die 2.10 geäußert

...
Ansonsten, die meisten Punkte Deiner Liste sind in anderen Systemen realisiert.

ich möchte aber eben nichts das System wechseln - dafür habe ich schon viel zu viel in modified realisiert 

Ich halt mich schon seit gestern zurück, hierauf zu antworten, weil ich nicht weiß, ob es dann ein kommerzieller Link ist, aber Modified als Multishop wurde bereits als kostenpflichtiges Modul gelöst und erfüllt so ziemlich die Anforderungen, die oben gestellt wurden.

Einfach mal "Modified Multishop" bei Google eingeben.

Tja, aber lieber hätte ich das im Core als eben noch einen weiteren Großbaustein in meinen angepassten Shop einzubauen...

Grüße
Dominik

[xxxxxxxxx]

Verstehe ich, aber das Modified von dem Du da sprichst, hätte nichts mehr mit dem Alten gemeinsam.

[webald]

Na ja, es gibt das schon eine Möglichkeit, indem man die verschiedenen Schichten des Shops ein bischen entkoppelt. Weil das was Voodoopupp sich da wünscht sind ja verschiedene Shops mit mehr oder weniger gleicher Datenbasis, aber nicht mehrere Anbieter in einem Shop.

Es wäre als nur eine Logik zu implementieren, die Daten zwischen Shops synchronisiert bzw. ggf. aus einem zentalen Datenbestand abruft. Die Grundlagen dafür sind fast fertig, ich muss noch die Verwaltungsoberfläche im Admin bauen und testen, dass ich nicht zuviel Bugs eingebaut habe. Meine REST-Service-Schnittstelle sieht schon von Haus aus verschiedene Mandanten/Domains vor. Aber ich brauch noch Zeit.

[voodoopupp]

Verstehe ich, aber das Modified von dem Du da sprichst, hätte nichts mehr mit dem Alten gemeinsam.

Wieso hätte es das nicht? Wo würde der "gravierende" Unterschied bestehen, also aus Händlersicht?
Das einzige wäre die Möglichkeit, den Shop auch für weitere Shops nutzen zu können.

Ich sehe halt auch einfach nur den ein oder anderen Konkurrenten (z.B. mit Oxid), der jede Menge kleinerer Shopableger mit angepasstem Angebot aus dem Boden sprießen lässt!

Und ich glaube, dass man mit aufgesplitteten Angeboten auch das passende Kundenklientel besser ansprechen kann und für die entsprechenden Themen/Marken etc. wesentlich besser ranken kann, als mit einem "Großen Shop"....

Grüße
Dominik

[voodoopupp]

Na ja, es gibt das schon eine Möglichkeit, indem man die verschiedenen Schichten des Shops ein bischen entkoppelt. Weil das was Voodoopupp sich da wünscht sind ja verschiedene Shops mit mehr oder weniger gleicher Datenbasis, aber nicht mehrere Anbieter in einem Shop.

Es wäre als nur eine Logik zu implementieren, die Daten zwischen Shops synchronisiert bzw. ggf. aus einem zentalen Datenbestand abruft. Die Grundlagen dafür sind fast fertig, ich muss noch die Verwaltungsoberfläche im Admin bauen und testen, dass ich nicht zuviel Bugs eingebaut habe. Meine REST-Service-Schnittstelle sieht schon von Haus aus verschiedene Mandanten/Domains vor. Aber ich brauch noch Zeit.

lass dir Zeit - ich bin ja echt gespannt, was du da baust

[webald]

Nur bitte nicht mißverstehen, das gibt keinen Multishop, nur eine REST-Schnittstelle.

[voodoopupp]

Das weiß ich, dennoch bin ich gespannt, was man alles mit dieser Schnittstelle machen kann!?
Da bin ich auch nicht genug im Thema, als dass ich mir da jetzt wirklich was zusammenreimen kann

Grüße
Dominik

[webald]

Du kannst Artikel aus der Wawi in de Shop bringen, Bestellungen abrufen, Daten aus anderen Shops abrufen, und das ohne Cron-Job, direkt beim Aufruf. Das ermöglich z. b. den Abruf des aktuellen Lagerbestandes eines Artikel in einem anderen Shop in einer anderen Domain auf einem anderen Server. Der wichtigste Vorteil: Man muss keine Kenntnis vom Shop haben, sondern nur wie man REST-Services aufruft.

[xxxxxxxxx]

Verstehe ich es richtig, das in diesem Falle nicht die Wawi die Informationen in Intervallen sendet, sondern der Shop quasi jede Artikelanfrage im Frontend von dieser Schnittstellen "abholen" muß ?