Welche Tabellenstruktur bei einem Variantengenerator

[etom291272]

:?: :?: :?: :?: :?: :?: :?:
Hallo DpLer :pale: Keine Ahnung wie ich folgendes Probelem realisieren könnte :pale:

Wir Haben die Anfrage einer unserer Kunden erhalten einen sogenannten Variantengenerator in eins unserer Erp Systeme zu implementieren.

Folgendes Beispiel soll verdeutlichen was mit Variantengenerator gemeint ist.
Es gibt eine Artikeldatenbank (soweit so gut)
Wenn jetzt der Anwender sagen wir ein Angebot schreibt und einen Artikel auswählt bei dem Varianten hinterlegt sind soll ein unterformular aufgehen wo jetzt bestimmte mehrdimensionale Unterkomponenten zu diesem Artikel auswählbar sind z.B In der ersten Combo wird Typ A gewählt den gibt es nur in Grün oder Rot also kann man in der nächsten Kombo nur mehr diese Farben auswählen Typ unterstützt wiederum unterschiedlich starke Motoren die dann in der nächsten Kombo richtig angezeigt werden müssen.
Montage kann an der Wand oder stehend erfolgen braucht man dan diese oder jene Halterung. :wall:

Ich hoffe ich konnte es anschaulich darstellen

:?: Frage 1 wie müsses die Tabellen und auch welche Tabellen in Beziehungen stehen um sowas zu realisieren

:?: Frage 2 wie kann man dem Benutzer eine Möglichkeit geben diese Varianten komfortabel einzugeben und auch ohne allzugrossen aufwand zu warten

wie gesagt bin ziemlich ratlos und freue mich über jeden vorschlag (gehen muss es ja Da ja jeder Online Konfigurator für Server im Internet so funktioniert :? )

Danke für eure Hilfe :dp:

[BrunoT]

Hi Tom,

ich würde den Artikelstamm mit Artikelgruppen versehen. Und zusätzlich bei dem Artikel, zu dem es Varianten gibt, die Artikelnummern oder die Artikelgruppe, welche variieren könnern. Die Variant-Artikel in einen String mit Seperator an den Artikel anhängen.

Ist nun nur die Artikelgruppe angegeben(z.B. Motoren) kann er in allen Motoren wählen, sind einzelne Artikelnummern angegeben, so werden diese nur zur Auswahl angezeigt.

Ich hoffe, ich konnte helfen

mfg

BrunoT

[etom291272]

@BrunoT

Danke für deine antwort die Eingenzungen bei den Umterkomponenten müssen aber wie gesagt von einander abhängig sein (wird zum Beispiel ein Raid Controller gewählt sind nur mehr SCSI Platten wählbar. Benutzer wählt 2 Scsi Platten -> wird zu Teuer schaltet wieder um aus SATA Platten muss Raid Controller verschwinden)

Deine Idee klingt aber nicht schlecht könntest du es vielleich ein bisschen genauer beschreiben

:cheers:

[BrunoT]

Also

Der Kunde Wählt einen SATA-Contr. , bei dem ist hinterlegt "SATA-Festplatten"(Artikelgruppe), Wenn er will, kann er auf (+) gehen und bekommt den Artikelstamm, diesesmal nicht nach Contollern, sondern nach SATA-Festplatten gefiltert angeboten.
Man könnte die so gewählten Sets als Set nummerieren(Set-Spalte, Set 1, Set 2 usw.).
Sollte das ihm zu teuer sein, könnte man das Set komplett löschen. :mrgreen:

Wählt der Kunde nun ein Motherboard, bekommt er nur die Prozessoren angeboten, die auf das Board passen, so ist hinterlegt:
"P123;P432;P654", im Filter für den Artikelstamm (oder Abfrage) werden nur diese Artikel angeboten.

Dei Wartung des Artikelstammes ist relativ einfach, man benötigt ein zusätzliches Eingabefeld für die Variant-Artikelgruppe und ein Feld für die Variantartikel. Über ein Zusatzfenster kann man im Artikelstamm blättern, und so die Artikel wählen, die man zusammenstellt. Zur Probe kann daraus der Filter gebildet werden, um die Unterauswahl zu überprüfen, nicht mehr existierende Artikel kann man automatisch aus dem Eingabefeld entfernen lassen. :!:

Fällt ein "Über-Artikel" weg, sind die Beziehungen auch weg, wie praktisch. :wink:

mfg BrunoT

[etom291272]

Ich fürchte das ganze ist nicht so schön 2 dimensional wie bei den beispielen es geht hier um Produkte der bauindustrie da kann es sein dass er in der 4. unter komponente in der 3. dimension etwas bestimmtes wählt und die unterkomponenten der oberen ebenen müssten sich austauschen.

:?:

[BrunoT]

Tja, dann würde ich zu fertig konfigurierten Sets raten, die in einer Extra-Tabelle stehn, und dann komplett in das Angebot übernommen werden.

Andererseits könnete man eine zusätzliche Eingabemöglichkeit für Voraussetzungen einbauen, wenn ich also eine Festplatte wähle, dass auch noch ein Einbaurahmen und ein Festplattenkabel hinzugefügt werden.

mfg

BrunoT

[etom291272]

Es ist nicht möglich alle denkbaren Kombinationen an Komponenten vorher in eine Tabelle zu hinterlegen (da würden warscheinlich 2 Büroleute 3 Jahre daran arbeiten) :wall:

darum bräuchte man eine Intelligenz dass die einzelnen unterkomponenten wissen von welchen darüberliegenden sie abhängig sind oder nicht

Für diese art von Beziehungen bräuchte ich eine Idee für die Tabellenstruktur

[BrunoT]

He,

nicht verzweifeln! :coder2:

So wie dargestellt, kommt es zu Zirkelbezügen und bei einer Automatik würde sich der Computer totlaufen und die Materialliste endlos werden.

Aber um auf mein Beispiel zurückzukommen, jedes Material kann natürlich sich bei seinem untergeordneten Material automatisch als Voraussetzung eintragen.

Man könnte das natürlich auch in drei Tabellen abbilden: Material, Voraussetzungen, Varianten

mfg

BrunoT

Nicht so kompliziert machen, die Sachbearbeiter müssen ja auch noch nachvollziehen können, was da passiert. :stupid:

mfg

BrunoT

[etom291272]

:-D :-D :-D

Es hört sich echt sehr logisch und zielführend an vielleicht wärst du so freundlich wenn du Zeit hast mir eine paar solche tabellen zu erstellen mit ein paar wenigen konkreten beipielen (die lösung mit den 3 Tabellen scheint mir am besten zu sein) da ich deinen Vorschlag gerne nachvollziehen würde

:cheers:

Danke für deine Zeit und Bemühungen

:dp: :coder: :coder: :coder:

[BrunoT]

Hi Tom,

hier ein Beispiel.

Ich hoffe, ich konnte helfen.

mfg

BrunoT