1x Frage (Artikel), 1xProblem(Varianten)

Deutsches Forum
1

Hallo Leute!

Hab mal ne Frage zur Produkt-Verwaltung…

Ich mach für einen Kunden nen Shop für Matratzen. Die Matratzen haben unterschiedliche Eigenschaften, welche ich im Oxid als Attribute angelegt habe.

Jetzt ist es aber schon 2mal vorgekommen, das ein neues Attribut zu allen Matratzen hinzukommt. In diesem Fall muss ich dann alle bis dahin angelegten Matratzen nochmal öffnen und die Attribute dort anpassen (allen Artikeln auf einmal ein Attribut zuweisen geht bei den Attributen, ich weis, jedoch wird dort nur das Attribut (der Attribut-Name) angefügt, aber kein Text (Attribut-Wert), z.b.:
Attribut-Name: Kern(Material)
Attribut-Wert: Federkern

Gibts da ne einfachere Lösung für sowas?! Auf Dauer ist das nämlich ziemlich aufwendig!

Das Problem hab ich aber nicht nur bei den Attributen, sondern auch z.b. beim alternativen “auf Lager”-Text, ich möchte jetzt im nachhinein, das bei allen Matratzen anstatt “sofort lieferbar” “Lieferzeit: 14 Tage nach Zahlungseingang” dasteht…

Und nun zu dem anderen Problem:
Die Matratzen gibt es ja in verschiedenen Größen, diese lege ich als “Varianten” an, da dort verschiedene Artikelnummern angegeben werden. Da sich die Varianten nur in der Artikelnummer und im Preis ändern, kopier ich immer eine vorhandene Matratze (Artikel kopieren) und änder einfach ab was abgeändert gehört. Jedoch passiert es ab und zu, dass die Thumbnails neben den Varianten nicht den, der neuen Matratze entsprechen, sondern der kopierten! Das ist meistens immer die erste oder die letzte Variante…Beispiel (Matratzen haben alle immer 5 Varianten):
[Thumbnail ArtNr.1000[B]1[/B]] Varianten-Titel
[Thumbnail ArtNr.10002] Varianten-Titel 2
[Thumbnail ArtNr.10002] Varianten-Titel 3
[Thumbnail ArtNr.10002] Varianten-Titel 4
[Thumbnail ArtNr.10002] Varianten-Titel 5

oder:

[Thumbnail ArtNr.10002] Varianten-Titel
[Thumbnail ArtNr.10002] Varianten-Titel 2
[Thumbnail ArtNr.10002] Varianten-Titel 3
[Thumbnail ArtNr.10002] Varianten-Titel 4
[Thumbnail ArtNr.1000[B]1[/B]] Varianten-Titel 5

Weis jemand über dieses Problem Bescheid?

Vielen Dank und Grüße,
infernalshade

2

Hallo Infernalshade,

Gibts da ne einfachere Lösung für sowas?! Auf Dauer ist das nämlich ziemlich aufwendig!

Das glaub ich gern. Wenn Du mir genauer spezifizieren kannst, wie so etwas aussehen könnte, kann ich einen Feature Request Eintrag machen.

Vom 2. Problem habe ich noch nix gehört.

Jedoch passiert es ab und zu …

… heißt, dass es nicht immer reproduzierbar ist? Lässt sich eine Abhängigkeit/eine Bedingung eingrenzen?

Gruß

3

Das glaub ich gern. Wenn Du mir genauer spezifizieren kannst, wie so etwas aussehen könnte, kann ich einen Feature Request Eintrag machen.

Es gibt ja wenn man ein Attribut anlegt eine Möglichkeit dieses Attribut gleich per Drag’n’Drop verschiedenen Produkten auf einmal neu zuzuweisen. Praktisch wäre es jedoch an dieser Stelle, das man einen “Standardwert” mit angeben kann. Ein Beispiel:
Produkt A-F haben Attribut 1-3.
Jetzt kommt ein Produkt G welches ein neues Attribut 4 hat (aber auch 1-3).
Bei Produkt A-F muss jedoch dieses neue Attribut 4 auch eingetragen werden.
Bei den Produkten A-F ist der Wert des Attribut 4 “Nein”, beim Produkt G “Ja”.

Wenn es beim zuweisen eine Funktion gäbe, gleich einen Standardwert mit anzugeben könnte ich “Nein” auswählen und dann beim Produkt G von “Nein” auf “Ja” wechseln. Bei vielen Produkten könnte sowas Stunden an Arbeit sparen!

Jedoch wäre grundsätzlich “Gruppenoptionen” nicht schlecht. Sprich man markiert in der Produktübersicht mehrere Produkte und kann mehrere auf einmal abändern (Attribute ändern, Varianten ändern, halt alles was sich bei den einzelnen Produkten nicht unterscheidet). Vor allem bei einem ziemlich ähnlichen Produktsortiment wäre das sehr hilfreich, in meinem Fall Matratzen, dort ändern sich nur die Attribute und die Kosten.

EDIT: Ein Beispiel ist mir noch eingefallen:
Angenommen der Kunde nimmt bei allen Matratzen eine neue Größe in sein Sortiment auf.
Dann müsste ich jede einzelne Matratze öffnen und dort eine neue Variante anlegen…

… heißt, dass es nicht immer reproduzierbar ist? Lässt sich eine Abhängigkeit/eine Bedingung eingrenzen?

Ja, bisher ist es willkürlich passiert, jedoch glaube ich das es eventuell an folgendem liegen könnte:
Man kopiert einen Artikel.
Um den Artikel speichern zu können (ohne Fehlermeldung) muss man eine neue Artikelnummer vergeben.
Hat man dann die Stammdaten abgeändert und klickt dann auf speichern wird der Artikel gespeichert, obwohl die Artikelnummern bei den Varianten noch die des vorher kopierten Produktes sind (Keine Fehlermeldung!). Nach dem Speichern geht man dann zu den Varianten und ändert dort auch die Artikelnummern ab.
Da ich beim anlegen der Produkte manchmal auf Speichern vor den Varianten geklickt habe und manchmal aber auch nicht, denke ich könnte hier der Hund begraben sein!
Als Artikelnummern habe ich:
Eltern-Produkt: 10001
Variante1: 10001-1
Variante2: 10001-2
Variante3: 10001-3
…

Grüße,
infernalshade

4

Hi,

ich zieh diesen thread nochmal hoch. Hat es vielleicht damit
http://www.oxid-esales.com/forum/showthread.php?t=2042 oder damit
http://www.oxid-esales.com/forum/showthread.php?t=2043
zu tun?

Dann sollten wir dort weiter diskutieren, wenn es möglich ist…

Gruß

5

[QUOTE=infernalshade;8297]Jetzt ist es aber schon 2mal vorgekommen, das ein neues Attribut zu allen Matratzen hinzukommt. In diesem Fall muss ich dann alle bis dahin angelegten Matratzen nochmal öffnen und die Attribute dort anpassen (allen Artikeln auf einmal ein Attribut zuweisen geht bei den Attributen, ich weis, jedoch wird dort nur das Attribut (der Attribut-Name) angefügt, aber kein Text (Attribut-Wert), z.b.:
Attribut-Name: Kern(Material)
Attribut-Wert: Federkern

Gibts da ne einfachere Lösung für sowas?! Auf Dauer ist das nämlich ziemlich aufwendig![/QUOTE]
Das ist ein generelles Problem [B]aller [/B]Shops die ich kenne, da ist standardmäßig viel Handarbeit angesagt, weil das System ja nicht weiß, welche Produkte welche Attribute bekommen sollen…

Für xtc/Gambio (deren Attribut-Verwaltung noch um einiges grauenvoller ist, als bei OXID) habe ich daher eine Lösung erarbeitet, die ich “[B]Standard Produkt-Attribute[/B]” und “[B]Standard Kategorien-Attribute[/B]” genannt habe.

Damit ist es möglich, (unsichtbare) “Pseudo”-Produkte zu definieren, deren zugewiesene Attribute automatisch entweder gezielt an [B]einzelne [/B]Produkte, oder [B]alle Produkte einer Kategorie[/B] “vererbt” werden. (Zusätzlich zu evtl. eigenen Attributen der Produkte.)

Damit lassen sich Aufgabenstellungen wie anfangs geschildert prima lösen…

(Evtl. wäre das auch ein Ansatzpunkt für eine OXID-Lösung.)

Das gleiche gibt es dann noch mal für die “[B]Cross-Sells[/B]”, da ja auch oft viele Produkte identische “Cross-Sells” haben.

[QUOTE=infernalshade;8297] Das Problem hab ich aber nicht nur bei den Attributen, sondern auch z.b. beim alternativen “auf Lager”-Text, ich möchte jetzt im nachhinein, das bei allen Matratzen anstatt “sofort lieferbar” “Lieferzeit: 14 Tage nach Zahlungseingang” dasteht…[/QUOTE]
Das lässt sich am einfachsten per SQL und PHPMyAdmin direkt in der Datenbank machen…

UPDATE `oxarticles` SET OXSTOCKTEXT='Lieferzeit 14 Tage nach Zahlungseingang'

Aber eigentlich wird hier ein echtes OXID-Problem angesprochen, das mir zunehmend weniger gefällt:

[B]Die Datenbank-Struktur ist m.E. weder richtig [U]relational[/U] noch [U]normalisiert[/U]![/B]

Wenn man sich z.B. die “[B]oxarticles[/B]”-Tabelle ansieht, stellt man fest, dass dort [B]viele [/B]Informationen statisch vorhanden sind, die eigentlich dort nichts zu suchen haben, sondern in externe Tabellen gehören! (Wie es z.B. das gute, alte xtc macht.)

[B]Ich rede von den Produkt-Namen, -Beschreibungstexten, -Bildern und -Lieferzeiten.[/B]

Dort sind für [B]bis zu 3 Sprachen[/B] (x) die Felder “OXTITLE_x,OXSHORTDESC_x,OXURLDESC_x, OXSEARCHKEYS_x” vorhanden. (Gilt auch für die Lieferzeiten-Texte.)

Wenn ich weniger als 3 Sprachen verwende, wird [B]Platz verschwende[/B]t, wenn ich mehr verwende, muss die [B]Datenbank-Struktur [/B]erweitert werden.

In xtc sind solche Daten in einer externen Tabelle untergebracht, die über SQL-“JOIN” mit der Artikel-Tabelle verknüpft werden. ([B]Relational[/B])

Für die Bilder gibt es folgende Felder “OXPIC1, OXPIC2 , OXPIC3 , OXPIC4 , OXPIC5 , OXPIC6 , OXPIC7 , OXPIC8 , OXPIC9 , OXPIC10 , OXPIC11 , OXPIC12 , OXZOOM1 , OXZOOM2 , OXZOOM3 , OXZOOM4”

Bei weniger als 12 Bildern und 4 Zoom-Bildern wird Platz verschwendet, bei mehr ist wieder Struktur-Änderung angesagt.

In xtc sind solche Daten (ab “OXPIC2”) in einer externen Tabelle untergebracht, die über SQL-“JOIN” mit der Artikel-Tabelle verknüpft werden. ([B]Relational[/B])
(Informationen über “Zoom”-Bilder werden dort gar nicht benötigt, da alle anderen Bildgrößen [B]automatisch [/B]aus dem Grundbild abgeleitet werden. Das gilt auch für [B]alle [/B]Zusatzbilder!)

In xtc sind auch die [B]Liefer-Informationen[/B] (für alle Sprachen) in einer externen Tabelle untergebracht, die über SQL-“JOIN” mit der Artikel-Tabelle verknüpft werden. ([B]Relational[/B], [B]normalisert)[/B]

[B]Da sollte OXID m.E. nachbessern, weil die jetzige Struktur nur Nachteile hat, unflexibel und einfach “unschön” ist…[/B]