Jobanfrage: Attributpflege

[Beedle]

Hallo,

ich benötige für jedes Artikelattribut Artikelnummern. Jedes Attribut soll in den Artikeln immer die gleiche Nummer erhalten, zum Beispiel:
Farbe - rot =1
Farbe - blau =2
Größe - 42 =3
....
Die Nummern sollen beim Speichern der Artieklattribute automatisch in die Datenbank geschrieben werden.

Für die Initialisierung brauche ich noch ein Skript das bei 1800 Artikeln die Nummern automatisch in die DB schreibt.

In der Bestellung soll die Artikelatributnummer nicht sichtbar sein, ich benötige Sie nur für eine Schnittstelle für den Bestellexport.

Angebote bitte per PN.

LG
Beedle

[MrEdge]

Hm an sich ist das (fast) mit den Bordmitteln von xt:C zu erledigen.

Zitat von Beedle

Hallo,

ich benötige für jedes Artikelattribut Artikelnummern. Jedes Attribut soll in den Artikeln immer die gleiche Nummer erhalten, zum Beispiel:
Farbe - rot =1
Farbe - blau =2
Größe - 42 =3
....

Wenn die Attribute im Adminmenü bearbeitest, kannst du ja zu jedem Attribut eine Artikelnummer festlegen, die mit der "Hauptartikelnummer" konkateniert wird.
Beispiel: Du hast ein Produkt "Schuh", Artikelnummer 567.
-das Merkmal "Größe" mit den Attributen und einzeln zugeordneten ArtikelNr: "42 -> 1, 43->2" etc
-das Merkmal "Farbe" mit "Rot -> 1, Blau ->2" etc
Wenn der Kunde dann den Schuh in 42, blau bestellt ergibt sich die Artikelnummer 56712 (1 für 42, 2 für blau). diese nummer bekommst du auch in der Bestellübersicht angezeigt. Leider gibt es dabei nachteile, zumindest wie ich nun nach kurzem nachschauen festgestellt habe:

-Diese "konkatenierte" End-Artikel-Nummer taucht in der datenbank nirgends auf (konnte sie jedenfalls nicht finden in orders_*), du müsstest dein Importer/Exporter also bemühen anhand der tabelle orders_products und orders_products_attributes wieder diese Zusammenzufiddeln zur End-Artikel-Nummer. (unschön dabei: die attribut referenzID (der primary key) wird nicht mitgepseichert, sondern leider nur der Merkmals- und Attributsname als String, also müsstest du beim Datenbank query den JOIN anhand des Strings machen, was zum nächsten nachteil führt: )

-die Attributnamen (die Strings) dürfen im Nachhinein nicht mehr geändert werden (bzw wenn dann nur mit entsprechendem SQL query in der ganzen DB auf einmal)

-die Attributereihenfolge darf nicht mehr verändert werden, neue attribute dürfen nur ans ende gestellt werden (sonst würden sich die artikelnummern ändern)

-du dürftest max 10 artikelattribute _insgesamt_ haben, oder aber von "Nummern" abweichen und auch zeichen oder gar ganze suffixe zulassen, zb 567-G1-F2 (-G1 als artikelnummer für größe 42, -F2 als artikelnummer für farbe 2 = blau etc)

In der Bestellung soll die Artikelatributnummer nicht sichtbar sein, ich benötige Sie nur für eine Schnittstelle für den Bestellexport.

Hm, in der Bestellübersicht ist sie sichtbar (und zwar konkateniert), in der Datenbank in orders_product jedoch nicht, weiss jetzt nich wie sich das weiter auf den rest des shops auswirkt.

Wenn du mit den obigen beschränkungen leben könntest solltest mal probieren dass so umzusetzen, wenn dass dann alles tut bräuchtest nur ein bisschen an der Bestellexportschnittstelle zu werkeln und kaum am shop selbst.
Lediglich die Funktion dass wenn du neue Produktattribute bearbeitest er automatisch die richtige artikelnummer vorselektiert, aber das sind nur ein paar zeilen code in einer einzigen datei, sollte also im rahmen sein.

Alle anderen Methode dürften jedoch ein ordentliches stück arbeit sein, gerade wegen der obigen beschränkungen/eigenheiten. Natürlich kann ich nun auch was auf die schnelle übersehen haben, ist schon spät

[Beedle]

Hallo MrEdge,

Beispiel: Du hast ein Produkt "Schuh", Artikelnummer 567.
-das Merkmal "Größe" mit den Attributen und einzeln zugeordneten ArtikelNr: "42 -> 1, 43->2" etc
-das Merkmal "Farbe" mit "Rot -> 1, Blau ->2" etc
Wenn der Kunde dann den Schuh in 42, blau bestellt ergibt sich die Artikelnummer 56712 (1 für 42, 2 für blau).

Genau das soll automatisch gehen, die Nummer ist dabei egal.

du müsstest dein Importer/Exporter also bemühen anhand der tabelle orders_products und orders_products_attributes wieder diese Zusammenzufiddeln zur End-Artikel-Nummer. (unschön dabei: die attribut referenzID (der primary key) wird nicht mitgepseichert, sondern leider nur der Merkmals- und Attributsname als String, also müsstest du beim Datenbank query den JOIN anhand des Strings machen, was zum nächsten nachteil führt: )

Die Schnittstelle ist oscware und genau die braucht die Nummern um die Attribute überhaupt erst zu exportieren. Ich habe lange mit Herr Hirche darüber diskutiert, aber er stellt den Zustand aus 2006, als es auch ohne diese Nummer ging, nicht wieder her. Da ich die Nummern nicht jedesmal pflegen will, möchte ich hier eine automatisierung.

Hm, in der Bestellübersicht ist sie sichtbar (und zwar konkateniert),

Das sollte nicht sichbar sein, der Code, der die Nummer zusammenbaut soll entsprechend geändert werden.

Wenn du mit den obigen beschränkungen leben könntest solltest mal probieren dass so umzusetzen, wenn dass dann alles tut bräuchtest nur ein bisschen an der Bestellexportschnittstelle zu werkeln und kaum am shop selbst.

Genau an dieser Stelle kann ich eben nicht werkeln. Ich habe hier auch schon eine Jobanfrage zu einer Schnittstelle die den Standart von Lexware anspricht gemacht, aber dort habe ich noch kein ernsthaftes Angebot.

Diese Lösung wäre eine Zwischenlösung bis ich was anderes habe als oscware.