Konfigurationsartikel mit 0 € vs. Preise der einzelnen Komponenten mit 0 €

[edding18]

Wir möchten einen Konfigurationsartikel anbieten, bei dem der Kunde insgesamt 2 Dosen bekommt und für Dose #1 und für Dose #2 jeweils eine Geschmacksrichtung auswählen kann.

Der Konfigurationsartikel an sich existiert nicht in der realen Welt, sondern ist nur ein logischer Artikel. Wir haben bisher folgende Konstellation gemacht:

Aktuelle Konfiguration

Konfigurationsartikel = 39,95 €
Dose #1 = 0 €
Dose #2 = 0 €

Vorteil:

- Der Konfigurationsartikel steht mit 39,95 € im Shop in der Artikelübersicht zur Auswahl
- Sonderpreise lassen sich problemlos umsetzen

Nachteil:

- Wenn die Bestellung in die Wawi importiert wird, haben wir dann den Konfigurationsartikel als "Vater" mit 39,95 € und die beiden konfigurierten Optionen mit jeweils 0 €. Hier kriegen wir dann bei dem Export-Formular CN23 ein Problem, da dort ja nur die "echten" Artikel auftauchen - also Dose #1 und Dose #2 und die mit 0 € drin stehen.

Lösungsansatz

Damit es sauber in die Wawi läuft, müsste der Auftrag, sobald er in der Wawi ist, dahingehend umgebaut werden, dass der Preis des Konfigurationsartikels (39,95 €) auf 0 gesetzt wird und die einzelnen Komponenten einen Preis bekommen (19,98 € + 19,97 €).

Alternative Konfiguration

Konfigurationsartikel = 0 €
Dose #1 = 19,98 €
Dose #2 = 19,97 €

Vorteil:

- Die Optionen sind mit einem nachvollziehbaren Preis im Auftrag drin. Das Export-Formular CN23 wird sauber durchlaufen.

Nachteil:

- Sonderpreise lassen sich nicht wirklich umsetzen!?
- Der Konfigurations-Artikel hat in der Artikelübersicht überhaupt keinen Preis. Es wird nur der Artikelname, nicht jedoch ein Preis angezeigt. Das Template sieht vor

<span class="price_label price_as_configured">{lang key='priceAsConfigured' section='productDetails'}</span>

und da steht dann "Preis wie konfiguriert"

Frage

- Mache ich etwas falsch?
- Wie würdet ihr das Thema lösen?

 

[edding18]

Ich bleibe wohl bei der bisherigen Lösung, werde aber mittels JTL REST API folgendes machen:

- Alle Positionen des Auftrags auslesen (API: Query Sales Order Line Items)
- Konfigurations-Artikel mitsamt den beiden Optionen (Dose #1 und Dose #2) löschen (API: Delete Sales Order Line Item)
- Die beiden Optionen wieder "solo" - also als ganz normale Artikel wieder hinzufügen und dabei den Preis des Konfigurations-Artikels sauber auf die beiden einzelnen Positionen aufteilen (API: Create Sales Order Line Item)

Ich muss sagen, die Ersteinrichtung der API wurde hier toll von JTL erklärt

und dank dem Postman kommt man schnell voran. Tipp: Man kann sich von Postman den cURL Code einer Abfrage generieren lassen und dann von ChatGTP in eine Programmiersprache der Wahl übersetzen lassen 😉