conShop

[Halchteranerin]

will sagen: ich glaub, datt is mir hier zu hoch..

keine Panik, die ist schon beendet. Es bringt ja nichts, HIER darueber zu philosophieren.

[kummer]

@HerrB

wie wichtig ist für dich die lagerbewirtschaftung ganz allgemein in einem shop-modul für contenido?

weil das problem ist, dass ich ohne grossen aufwand keine gute lösung finden kann. grundsätzlich kann man die entsprechenden daten wohl serialisiert in der datenbank speichern. soweit keine problem. allerdings möchte man bei einer lagerverwaltung die entsprechenden daten von einer externen quelle einbeziehen. und dann ist nichts mit serialisierten daten.

wenn wir nur von einer option sprechen würden, der eine anzahl lagerwaren zugeordnet werden muss, wäre es im übrigen kein problem. wäre das nicht auch ausreichend? ich denke da z.b. an t-shirts, wenn die farbe und die grösse massgeblich ist, müsste man in diesem fall für jede farbei ein produkt erstellen und für jede grösse (die dann als option gehandhabt werden würde) einen lagerbestand erfassen. auch zwei optionen wären im übrigen noch keine problem. die frage ist bloss, brauchen wir in der praxis wirklich eine unbegrenzte anzahl optionen, die lagerbewirtschaftungstechnisch von bedeutung sind? aus meiner sicht wären zwei optionen ausreichend und auch noch im erd unter zu bringen.

bin auf deine meinung gespannt. im übrigen auch auf die aller anderen. es ist ja eine offene diskussion für ein offenes produkt.

in diesem sinn: so long!

gruss,
andreas

[phpchris]

Ich schließe mich kummer an.
Schließlich soll das Produkt im Endeffekt eine kleine Ergänzung zu Contenido sein und kein OSC / XTC Ersatz sein.
Ich stehe auch hinter der Meinung von HerrB, dass solch ein Plugin auch eine Lagerverwaltung mit sich bringen sollte.

Ich meine einfach, dass es alles im Rahmen bleiben sollte, oder?

[kummer]

die frage ist natürlich auch prinzipieller natur. unabhängig davon, wie gross das ganze angeplant werden soll und wird.

ich werde mal versuchen, das ganze so wie vorgeschlagen in das erd zu integrieren und werde das dann an dieser stelle publizieren.

die frage ist übrigens noch offen, ob und wer sich der produkteklasse annehmen wird. ich hoffe mal, dass sich unter denjenigen, die sich gemeldet haben, jemand findet, der auch dann noch dabei ist, wenn es konkret wird...

[HerrB]

Wie ein paar Seiten vorher erwähnt, denke ich mal drüber nach. Natürlich sollte es möglichst einfach sein.

Wenn, dann sollte es aber möglichst allgemeingültig sein - eine Begrenzung auf n wichtige Optionen führt automatisch zum n+1. Bedarf (und da dann nochmal ran zu müssen, würde ich mir nicht antun wollen).

Was mir gerade so einfällt (und wie gesagt, ich denke noch):
Eine Datenspeicherung kann seeeeehr einfach sein: Es gibt zwei Arten von Optionen:
1. Freie Optionen (z.B. bei einer Wand: die verwendete Farbe [sagen wir mal, die kostet immer das Gleiche] - das ist ein Preis und die Verfügbarkeit ist unendlich),
2. Gebundene Optionen (alles, was durch die Kombination ein eindeutiges Produkt definiert)

Bei 1. stelle man sich z.B. die Farbe rot, weiß, blau usw. vor. In xtCommerce kann ich übrigens pro Artikel bestimmen, welche Optionswerte für den Artikel möglich sind (weil es vielleicht die eine Wand nicht blau gibt...) - nett.

Bei 2. habe ich die Optionen Größe, Farbe und Ausführung. Die verfügbaren Werte für jede Option kann ich zentral festlegen.

Dann definiere ich den Artikel und kann dabei angeben, welche gebundenen Optionen ich verwenden möchte (genau genommen sollte man sogar die verfügbaren Werte pro Artikel festlegen können - wenn es einen Artikel in Größe XL gar nicht gibt, ist das eine andere Aussage, als das der Lagerbestand des Artikels in Größe XL 0 ist).

In einem anderen Fenster kann ich pro Variation den jeweiligen Wert der Option festlegen (z.B. XL, weiß, runder Kragen) und Preis und Lagerbestand angeben.

Es handelt sich also um zwei verschiedene Optionstypen, die so auch in der DB berücksichtigt werden müssen.

Und weil es vielleicht verwirrend ist: Option ist z.B. Größe, Optionswert ist z.B. XL, L, M, ...

Rein db-technisch würde ich das dann übrigens so lösen, dass ein Artikel (=Contenido-Artikel) immer über eine Variation verfügt: Die Standardvariation (speichert Preis und Lagerbestand, wenn keine weitere Variation festgelegt wurde).

D.h.
Ich habe als Tabellen
- Artikel (= schon da)
- Freie Optionen
- Werte für freie Optionen
- Mögliche Werte der freien Optionen pro Artikel (d.h. ich kann pro Artikel sagen, ob rot als Farbe [freie Option] gewählt werden kann)
- Gebundene Optionen (mit u.a. 0 - Standard)
- Werte für gebundene Optionen (mit u.a. 0 - Standard)
- Mögliche Werte der gebundenen Optionen pro Artikel (d.h. ich kann sagen, dass als Größe XL und L und als Farbe rot und blau möglich sind) (mit u.a. 0 - Standard)
- Verfügbare Variationen mit Preis und Lagerbestand pro Variation

Ich habe mir das noch nicht gegen den aktuellen Designvorschlag angesehen, da dürfte es noch Überschneidungen geben. Ich sehe es mir noch an.

Gruß
HerrB

[kummer]

also, ich habe jetzt - so glaube ich mindestens - alle denkbaren anforderungen ganz oder teilweise in das erd integriert. zusammen mit der mehrsprachigkeit (die ich ganz persönlich als vordringlich wichtig halte), ergibt sich ein inzwischen nicht mehr ganz einfaches erd, welches notabene erst einmal die artikel enthält.

in der jetztigen version wäre die speicherung folgender daten möglich:

1. bezeichner (in allen verfügbaren sprachen)
2. preis
3. währung
4. einheiten, in denen das produkt angeboten werden kann (eine zulässige auswahl wäre dann die einheit oder ein vielfaches davon)
5. zwei optionen, für die in kombination eine lagerverwaltung vorgenommen werden kann (auch wieder in allen verfügbaren sprachen)
6. eine unbegrenzte anzahl weiterer optionen (die allerdings für die lagerverwaltung unerheblich sind, ebenfalls in allen sprachen)
7. die für das produkt massgebliche steuerklasse

die integration von n möglichen und für den lagerbestand bedeutenden optionen ist aus meiner sicht im erd sauber kaum unter zu bringen. ich habe es deshalb einmal auf zwei begrenzt. ich nehme an, dass das in der überwiegenden zahl von fällen mehr als ausreichend sein sollte. wenn jemand eine gute lösung weiss, bin ich gerne dafür zu haben.

das erd sieht jetzt also wie folgt aus:



ich warte auf response...

[kummer]

übrigens zu der frage unbgrenzter für den lagerbestand bedeutender optionen: es muss ja eine tabelle bestehen, die die möglichen optionen als fremdschlüssel enthält und dann noch den aktuellen lagerbestand. das problem ist nun das, dass ich bei der definition der tabellen wissen muss, wieviele fremdschlüssel vorzusehen sind. egal wieviele es sind: die zahl ist begrenzt.

die einzige möglichkeit, dieses problem zu umgehen, wäre, die schlüssel der optionen in jeder denkbaren weise mit einander zu kombinieren (=kartesianisches produkt), zu sortieren, duplikate auszuschliessen und mit dem so erstellten neuen zusammengesetzten schlüssel den lagerbestand zu verknüpfen. eine direkte abfrage, ohne zuvor den zusammengesetzten schlüssel jedesmal auf genau diese weise wieder herzustellen, wäre dann völlig unmöglich.

in der folge treten folgende zwei probleme auf:

1. die performance leidet stark und mit zunehmender anzahl produkte und optionen immer mehr
2. ein import oder ein bezug auf die daten von einer anderen anwendung ohne interface ist nahezu unmöglich

ich hoffe, dass die im erd integrierten zwei optionen (für den lagerbestand) sowie daneben der unbegrenzten anzahl freier optionen für die anwendung als shop ausreichend sind.

als beispiel. es wäre jetzt (mit obigen erd) möglich, bei einem kleidungsstück sowohl die farbe als auch die grösse zu wählen und den aktuellen lagerbestand zu sehen. eine dritte, vierte und fünfte option könnte ohne weiteres ebenfalls angegeben werden. für diese und die daraus entstehenden kombinationsmöglichkeiten könnte allerdings einfach kein lagerbestandswert aufgenommen werden.

allerdings muss man sich bei allen einschränkungen, die diese lösung sicher mit sich bringt, auch eines bewusst sein (oder bewusst machen): man könnte im extrem fall verlangen, dass ein shop mit nur einem einzigen produkt auskommen muss und alle denkbaren kombinationen einfach aus optionen zusammen zu stellen. dieses beispiel ist nicht so absurd, wie es vielleicht den anschein haben mag. gehen wir zum beispiel von 2 optionen und je 10 verschiedene werten aus, die jede option haben kann, dann ergeben sich bereits 100 verschiedene lagerbestände. bei drei optionen und gleicher anzahl werte sind es bereits 1000. und nehmen wir bei gleicher annahme (10 werte je option) an, es gäbe zum beispiel 5 optionen, dann sind wir bereits bei 100'000 kombinationen. ich denke, das ist auch für einen grossen shop viel, sehr viel sogar.

oder ein anschauliches beispiel. ein kleiderhersteller hat ein und dasselbe kleidungsstück in z.b. 10 farben, 7 verschiedenen grössen, in 5 verschiedenen stoffen und 6 aktuellen schnitten an lager (das sind gerade mal 4 optionen). das wären dann bereits schlappe 2100 verschiedene kombinationen. ich gehe mal davon aus, dass in solchen fällen (bei einer grossen anzahl kombinationsmöglichkeiten) kein lagerbestand mehr vorgenommen werden würde. wenn wir davon ausgehen, dass der shop vielleicht 1000 verschiedene artikel enthält, dann müsste dieser shop (wir sprechen von einem shop in contenido, nicht vergessen!) 2.1 millionen kleidungsstücke wenigstens je einmal an lager halten (und fortwerfen, wenn er sie nicht verkaufen kann). und wiederum: er wird jedes stück mehr als einmal an lager halten wollen, sonst lohnt sich lagerhaltung nicht. sagen wir z.b. er hält 50 stück an lager: wir sind inzwischen bei 105 millionen artikel angelangt...

[kummer]

good news! ich habe eine lösung gefunden. ich brauche noch einen moment, um das erd anzupassen.

dann haben wir zwei verschiedene optionen und können dann entscheiden, von welchem wir ausgehen wollen.

bis spätter...

[kummer]

also, ich habe das erd fertig:



die eine oder andere erklärung dürfte noch erforderlich sein, weil die verknüpfung gelinde gesagt etwas unorthodox ist.

die tabelle con_conShopOptionValue enthält einen schlüssel mit der bezeichnung opv_singleKey. in dieses feld ist ein - in kombination mit dem fremdschlüssel fk_product - eindeutiger bigint der menge aller zweierpotenzen einzugeben (also: 2^0, 2^1, 2^2, 2^3, usw.). die verknüpfung mit der tabelle con_conShopStock erfolgt einerseits konventionell zum produkt und andererseits durch die speicherung der summe aller in einer bestimmten kombination auftretender optionswerte (summe der opv_singleKey). der entsprechende wert wird im feld fk_singleKeySum gespeichert. die summe der zweierpotenzen ist ebenso eindeutig, wie die einzelnen zweierpotenzen. ein umstand, der sich als sehr nützlich erweist.

ist der lagerbestand für eine bestimmte kombination von optionen zu ermitteln, müssen lediglich deren opv_singleKey addiert werden und damit die tabelle con_conShopStock abgefragt werden.

@HerrB: ist das in etwa, was du dir vorgestellt hast?

bin auf antworten gespannt.

mfg,
andreas

ps: ach ja, eine kleinigkeit noch: bei der option selber hat es noch ein feld vom typ tinyint für die speicherung, ob eine option für den lagerbestand überhaupt von bedeutung ist oder nicht.

[kummer]

jetzt sind inputs gefragt. die zweite präsentierte lösung hat sich als erstaunlicherweise weniger komplex heraus gestellt als ursprünglich angenommen.

ich wäre einfach froh, wenn sich das jemand anschauen und mir mitteilung machen könnte, ob das erd so in ordnung sei.

danke im voraus!

gruss,
andreas

[HerrB]

Ich gucke es mir an, wird aber ein paar Tage dauern (bei sowas brauche ich Stunden, um das zu durchschauen... ).

Gruß
HerrB

[kummer]

bei fragen einfach melden. es ist eine etwas seltsame verknüpfung, die ich habe machen müssen. aber es ist eben halt auch eine knacknuss, diese anforderung...

[jost]

Für's Wochenende vorgenommen Schon einmal Danke für das Heft-in-die-Hand nehmen.

[HerrB]

Ich habe es noch nicht ganz durchdrungen, aber ich denke, folgende Punkte sollten noch berücksichtigt werden:

- Jede (stockrelevante) Kombination kann ihren eigenen Preis haben, d.h. der Preis oder der Aufpreis müssten vermutlich in conShopStock enthalten sein (ein T-Shirt in XL kostet mehr als ein T-Shirt in S).
- Optionen und Optionswerte sollten zentral festgelegt werden. Nur die Auswahl, welche Option mit welchen Werten für das Produkt genutzt werden kann, ist conShopProduct-related. Wenn ich das ERD richtig verstehe, muss ich für jedes Produkt jede Option und jeden Wert erneut anlegen (richtig?).
- Wie ist conShopCurrencies in Verbindung mit conShopProduct gemeint? Ist die Angabe in conShopProduct die "erste" Currency und bei Auswahl einer anderen wird umgerechnet? Ich vermute mal nicht - dann könnte man das nochmal umfummeln: conShopCurrencies bekommt ein "cur_default" flag und ein Feld "cur_factor", fk_currency in conShopProduct entfällt. Der Preis bei conShopProduct (oder in conShopStock) entspricht dem Preis der Standard-Currency, der Faktor gibt den Umrechnungsfaktor zur Basis-Währung an.

Bei der Mehrwertsteuer kenne ich mich nicht so aus: Wenn ein Ausländer bestellt, welche Steuer muss erhoben werden? Da ich da noch etwas erwarte, denke ich, dass auch conShopTax anders organisiert werden muss (vermutlich in Abhängigkeit mit einem Land, aus dem man bestellt).

Kannst Du mal ein Beispiel zu opv_SingleKey und fk_singleKeySum beschreiben (ich glaube, es ist eine geniale Idee, mir fehlt nur noch ein konkretes Beispiel). Danke.

Gruß
HerrB

[kummer]

hallo HerrB

1. den preis kann man noch einfügen. respektive, wenn man keinen preis angibt, dann wird der produktpreis verwendet. dazu gehört dann natürlich wieder die währung (analog dem produkt selber).
2. ich habe die optionen bewusst nicht zentral gesteuert. der grund ist einfach. jemand hat cds oder dvds ohne optionen, dann t-shirts mit optionen grösse und farbe und schnitt und dann nochmals ein produkt mit irgendwelchen anderen optionen. die wahl ist bewusst so erfolgt. wenn ich z.b. eine option nur genau bei einem produkt habe (und sonst nie), müsste ich es zentral einpflegen und dann bei den anderen wieder angeben, dass es eben nicht verfügbar sei. und z.b. die farbe. die wäre dann nicht bei jedem kleidungsstück gleich. da halte ich die redundante speicherung für sinnvoll.
3. bei de währung verhält es sich genau so, wie du annimmst, dass es nicht der fall sei. also zum preis wird auch die währung erfasst, in der die angabe erfolgt ist. bei der ausgabe wird die währung der preisangabe, der preis selber sowie die zielwährung berücksichtigt.
4. bei der mehrwertsteuer habe ich einfach mehrere mehrwertsteuerklassen vorgesehen. in den meisten fällen ist es so, dass die mehrwertsteuer des herkunftslandes massgeblich ist. da der shop in irgendeinem land beheimatet ist, spielen die übrigen mehrwertsteuersätze keine rolle. als sender kann ich immer nur meine eigene mehrwertsteuer abrechnen. oder keine, falls das für ein land so vorgesehen ist (z.b. bei lieferung von der schweiz nach deutschland). aus meiner sicht ist das erd in dieser hinsicht in ordnung.
5. bezüglich der verknüpfung schreibe ich ein kleines beispiel. kommt in kürze. aber dazwischen muss ich noch rasch etwas machen, mit dem ich geld verdiene... aber es dauert nicht lange.