Neu WARNUNG JTL GPSR Plugin 1.0.2 funktioniert nicht, wenn Artikel keine Beschreibung hat

[John]

Jo, die Überschrift sagts. Hat der Artikel keine (Haupt-) Beschreibung, wird der GPSR Bereich nicht angezeigt.
Shop 5.34, keine Template Änderungen.

Ticket 202412023602617 offen.

@Moderatorenteam: Könnte ihr das Ticket bitte intern anschieben?

John

 

[John]

Der Support dazu:

das ist korrekt, eine Beschreibung ist Pflicht. Das ist kein technischer Fehler.

Das ist deshalb erforderlich weil auch eine Ausführliche Beschreibung immer vorhanden sein muss laut GPSR.

Ich sehe das nicht so.
Man kann der Pflicht einer Beschreibung auch durch andere Möglichkeiten nachkommen, z.B. in der Kurzbeschreibung, Bilder, Merkmal oder einem PDF Anhang.

Aus meiner Sicht handelt es sich mindestens um einen Seiteneffekt des Plugins, der dokumentieren sein muß.
Den Grund, das Plugin gar nicht ausgeben zu lassen und damit die rechtliche Situation noch zu verschlimmern, kann ich nicht nachvollziehen.

Meinungen?

 

[ergowebshop]

Du kannst doch im Plugin einstellen an welcher Stelle die Angaben angezeigt werden. Dann nimm halt nicht nach Beschreibung sondern nach Bewertung oder so.

Ich würde dir ja gerne sagen wie wir das eingestellt hatten, aber bei uns ist die Auswahlliste merkwürdigerweise leer. 😒

 

[John]

Es geht doch darum, was die Standardeinstellungen des Plugins sind und was ich als Softwarehersteller meine Kunden angedeihen lassen.
Das sollte doch maximal fail-safe sein.
Würdest Du es gutheißen, ABS im Auto unkommentiert abzuschalten, wenn der Fahrer seinen Führerschein nicht dabei hat?
Nein und genauso sollten GPSR da sein, selbst wenn die Beschreibung fehlt.

Ich finde es schwierig, wenn das tatsächlich JTL Philosophie im Bezug auf Rechtssicherheit ist.

Aber gut, die Experten-Einstellung soll die Lösung sein:
Bitte nenn mir die korrekten Einstellungen im Plugin, die die GPSR Infos immer und möglichst weit unten einblenden und das frei von anderweitigen Bedingungen.
Ich kann selbst mit ordentlich Erfahrung nicht abschätzen, welche andere Auswahl evtl. welche Bedingung voraussetzt.

John

 

[rshost.eu]

Es geht doch darum, was die Standardeinstellungen des Plugins sind und was ich als Softwarehersteller meine Kunden angedeihen lassen.
Das sollte doch maximal fail-safe sein.
Würdest Du es gutheißen, ABS im Auto unkommentiert abzuschalten, wenn der Fahrer seinen Führerschein nicht dabei hat?
Nein und genauso sollten GPSR da sein, selbst wenn die Beschreibung fehlt.

Ich finde es schwierig, wenn das tatsächlich JTL Philosophie im Bezug auf Rechtssicherheit ist.

Aber gut, die Experten-Einstellung soll die Lösung sein:
Bitte nenn mir die korrekten Einstellungen im Plugin, die die GPSR Infos immer und möglichst weit unten einblenden und das frei von anderweitigen Bedingungen.
Ich kann selbst mit ordentlich Erfahrung nicht abschätzen, welche andere Auswahl evtl. welche Bedingung voraussetzt.

John

Hier ist der Fall ohne Artikelbeschreibung im offiziellen Guide beschrieben:

https://guide.jtl-software.com/jtl-...en-plugin-einstellungen-aendern-nova-template

 

[Rainer S]

Es geht doch darum, was die Standardeinstellungen des Plugins sind und was ich als Softwarehersteller meine Kunden angedeihen lassen.
Das sollte doch maximal fail-safe sein.
Würdest Du es gutheißen, ABS im Auto unkommentiert abzuschalten, wenn der Fahrer seinen Führerschein nicht dabei hat?
Nein und genauso sollten GPSR da sein, selbst wenn die Beschreibung fehlt.

Ich finde es schwierig, wenn das tatsächlich JTL Philosophie im Bezug auf Rechtssicherheit ist.

Aber gut, die Experten-Einstellung soll die Lösung sein:
Bitte nenn mir die korrekten Einstellungen im Plugin, die die GPSR Infos immer und möglichst weit unten einblenden und das frei von anderweitigen Bedingungen.
Ich kann selbst mit ordentlich Erfahrung nicht abschätzen, welche andere Auswahl evtl. welche Bedingung voraussetzt.

John

Nur dazu, da gibt es auch einen Link zu FAQ:

https://guide.jtl-software.com/jtl-shop/systemverwaltung/faq-zu-jtl-shop/

 

[css-umsetzung]

Ein wichtiger Hinweis hierzu:

Ihr dürft keine Datei auswählen, die Ihr über euer Child Template modifiziert habt, da sonst alle Modifizierungen hinfällig sind.

https://issues.jtl-software.de/issues/SHOP-8431

 

[John]

Ahja, mein Fehler dann, weil ich die Doku zu dem Plugin, die im Guide in den FAQs versteckt ist und eben nicht wie zu Erwarten im Plugin verlinkt, nicht gelesen habe.

Wem das wohl noch so geht...

 

[ergowebshop]

Es geht doch darum, was die Standardeinstellungen des Plugins sind und was ich als Softwarehersteller meine Kunden angedeihen lassen.
Das sollte doch maximal fail-safe sein.

Also die Standardeinstellung hat bei uns dazu geführt, dass das "Zweispaltige Artikelmerkmale - ekokoro" Plugin nicht mehr funktionierte.

 

[deliman]

Also die Standardeinstellung hat bei uns dazu geführt, dass das "Zweispaltige Artikelmerkmale - ekokoro" Plugin nicht mehr funktionierte.

Ja, kann ich bestätigen. Ist bei uns auch so. Da muss man wohl die ekokoro-Leute mal draufhinweisen...

 

[NoOne]

Ich finde es schwierig, wenn das tatsächlich JTL Philosophie im Bezug auf Rechtssicherheit ist.

Du vergisst dabei, dass es bereits ohne Eingabemasken in der Wawi und ohne Shop-Plugin möglich ist, den JTL-Shop rechtssicher zu gestalten. Nur aufwändiger. Bei allem, was flexibel ist, können Dinge schiefgehen. Wenn du auf Nummer sicher gehen möchtest, dass die GPSR-Angaben immer vorhanden sind und angezeigt werden: Hinterleg sie manuell am Artikel. In der Beschreibung etwa. Da bist du auch völlig frei in der Gestaltung. Das automatisiert zu haben, ist praktisch, aber eigentlich unnötig und damit Luxus. Manuell funktioniert das auch noch mit der Wawi 1.5 und Shop 4. Und genau wie JTL die vereinfachungen dazu schon früher hätte implementieren können, hätte man als Shopbesitzer die nötigen Daten auch schon über die Zeit manuell pflegen können.

Oder die Hersteller hätten ihre CSV-Importe einmal mit und einmal ohne GPSR-Angaben in der Beschreibung anbieten können.

Für die Rechtssicherheit ist jeder selbst verantwortlich. Vor allem, wenn alles nötige ohnehin schon vorhanden ist.

 

[John]

@NoOne Für die Rechtssicherheit ist jeder selbst verantwortlich, ist der Standardspruch, mit dem sich Dienste- und Softwareanbieter bisher gerne raus reden und den Du nur so lange gelten lässt, bis Du selbst die Probleme bekommst.

Fakt ist:
JTL bewirbt mit dem Plugin eine Lösung. Offensiv via Newsletter und für technisch wenig erfahrene Nutzer installierbar.

Warum ist dieses Plugin nicht maximal-failsafe in den Standardeinstellungen und bindet an einen Block, der immer angezeigt wird?

Zudem fehlt in der Doku des Plugins, d.h. in den Einstellungen im Backend und auf der Extension Store Seite der Hinweis, dass das Plugin evtl. nichts anzeigt, wenn die Beschreibung fehlt.
Das ist die Doku die relevant ist und die man liest und nicht irgendwo anders im Guide.

Wenn ich das programmiert hätte:
1. failsafe Standardeinstellung
2. Fetter Hinweis auf nötige Bedingungen, wenn man die Standardeinstellung verändert
3. Optional im Backend eine Prüfung, ob alle Artikel eine Beschreibung haben - ist in SQL kein Hexenwerk.

Dieses Plugin ist sowieso schon eine unschöne Lösung, die utopische Mengen Attribute in der Datenbank erzeugt und dann ist sie nichtmal betriebssicher in den Standardeinstellungen.
Ob des Wissens seitens JTL ist das fahrlässig.

 

[NoOne]

Für die Rechtssicherheit ist jeder selbst verantwortlich, ist der Standardspruch, mit dem sich Dienste- und Softwareanbieter bisher gerne raus reden und den Du nur so lange gelten lässt, bis Du selbst die Probleme bekommst.

Nö. Das ist Fakt, wenn es Möglichkeiten gibt, die Rechtssicherheit herzustellen. Wie aufwändig oder lästig das ist, sei mal dahingestellt.

JTL bewirbt mit dem Plugin eine Lösung. Offensiv via Newsletter und für technisch wenig erfahrene Nutzer installierbar.

Ist auch für technisch unerfahrene Nutzer installierbar. Und der Guide dazu ist halt auch vorhanden. Und der Hinweis auf die FAQ, falls die GPSR-Informationen nicht angezeigt werden, findet sich hervorgehoben weit oben im Guide:

1. failsafe Standardeinstellung

Nicht möglich, wenn Templates jederzeit modifiziert sein könnten.

2. Fetter Hinweis auf nötige Bedingungen, wenn man die Standardeinstellung verändert

Siehe oben. Du kennst die nötigen Bedingungen nicht. Für NOVA, ggf. für alle anderen: Nope.

3. Optional im Backend eine Prüfung, ob alle Artikel eine Beschreibung haben - ist in SQL kein Hexenwerk.

Könnte man machen, aber wozu? Ein Händler sollte wissen, ob seine Artikel alle eine Beschreibung haben oder nicht -> Ressourcenverschwendung.

Dieses Plugin ist sowieso schon eine unschöne Lösung, die utopische Mengen Attribute in der Datenbank erzeugt und dann ist sie nichtmal betriebssicher in den Standardeinstellungen.
Ob des Wissens seitens JTL ist das fahrlässig.

Dieses Plugin ist die abwärtskompatible Lösung für alle, die kein Shop-Update vornehmen möchten, bzw. nicht auf ein Shop-Update warten möchten. Und eigentlich bestand hier generell gar keine Verpflichtung, dass überhaupt extra zu lösen. Es wurde versucht, das für die Kunden zu vereinfachen. Das ist eher nicht gelungen. Aber damit sitzen die Kunden nicht auf dem Trockenen (zumindest nicht für den JTL-Shop). Weil es eben auch vorher schon möglich war, den GPSR-Richtlinien zu genügen. Und zwar absolut problemlos. Nur aufwändiger.

Das lehrt, wie immer, nur eines: Einen Plan B (C, D, E, F...) haben. Wirklich verlassen kann man sich immer nur auf sich selbst.

 

[John]

Der fette Hinweis ist irgendwo im Guide aber nicht im Plugin oder der Doku des Plugins, dort wo man als Nutzer sowas erwartet.

Ich denke, ist auch alles gesagt.
JTL sieht kein Problem, Du auch nicht und der Rest zahlt halt irgendwann die Abmahnung.

 

[css-umsetzung]

Könnte man machen, aber wozu? Ein Händler sollte wissen, ob seine Artikel alle eine Beschreibung haben oder nicht -> Ressourcenverschwendung.

Naja, Ressourcenverschwendung ist es, wenn ein Plugin jetzt auf jeder aufgerufenen Seite, bis zu 70 Abfragen durchführt, ob die im Plugin eingestellte tpl Datei von smarty gerade geparst wird.
Ressourcenverschwendung ist es auch, wenn ein Hersteller mit seinen Kontakt Daten, in der Datenbank mehrere 1000 Mal hinterlegt ist.

Es hätte bessere Wege gegeben, das umzusetzen (auch wenn man es über ein Plugin regelt, damit es auch in 5.1er Shops genutzt werden kann).
Hinzu kommt, dass wie es scheint ja noch immer nicht alle Daten an den Shop gesendet werden.

Ich bin nicht begeistert davon, wie es umgesetzt wurde,

 

[www-carhifidesign-de]

Hallo,
Herstellerangaben funktioniert so weit jetzt mit dem neuen Update.
Kleines Problem hab ich aber gefunden.
für USA ist nur die Angabe / Vereinigte Staaten / wohl nicht ganz korrekt
Auch sind nicht alle Bundesstaaten ausgeschrieben. Ich bräuchte z.B Arizona
Bekomme aber bei der Auswahl Liste nur "Unknown AZ" angezeigt.
sind auch noch mehrere Staaten wo Unknown dabei steht und nur das kürzel.
Sieht ehrlich gesagt etwas scheiße aus wenn das so bei den Herstellerangeben steht.

 

[NoOne]

Es hätte bessere Wege gegeben, das umzusetzen (auch wenn man es über ein Plugin regelt, damit es auch in 5.1er Shops genutzt werden kann).
Hinzu kommt, dass wie es scheint ja noch immer nicht alle Daten an den Shop gesendet werden.

Es ging dabei nicht nur um den Shop. Sondern auch darum, nicht 5 verschiedene Lösungen für 5 verschiedene Plattformen zu haben und abwärtskompatibel zu sein. Das gabs eigentlich keine andere Möglichkeit. Hätte es seit jeher Herstellerattribute gegeben, dann wär das vermutlich auch ganz anders gekommen. Aber das, was jetzt mit der 1.9.6.X ist, ist in der Tat unschön. Und auch, dass das für den JTL-Shop immer noch auf den Funktionsattributen beruht. Aber hier wurde halt auch erst der erste Step gemacht. Die Wawi wurde angepasst, was die Masken betrifft. Der Shop-Core noch gar nicht. Jetzt muss der Shop nachziehen und dann muss der Abgleich angepasst werden. Wawi-Update im Weihnachtsgeschäft ist schlimm genug. Pflicht Shop-Update dazu und das Geschrei wäre ebenfalls groß gewesen.

Die GPSR-Daten in die Beschreibung zu hauen, wäre ein Space<>Time-Tradeoff gewesen. Auf die Performance hätte das weniger Auswirkungen gehabt als die Funktionsattribute, aber nicht unbedingt weniger Platz gefressen. Das einpflegen wäre für den 08/15 Nutzer aufwändiger gewesen. In die Herstellerbeschreibung hauen und per Plugin parsen, was Beschreibung und was GPSR-Daten sind, hätte für den JTL-Shop gepasst. Aber nicht für eBay/Amazon etc. pp. Jedenfalls nicht ohne Wawi-Update, damit die das ebenfalls parsed.

Die Funktionsattribute waren praktisch die einzige Möglichkeit das Plattformübergreifend zu machen ohne irgendein Update fahren zu müssen und die Daten "getrennt" vorliegen zu haben. Ist natürlich trotzdem traurig, dass die endgültige (komfortable) Lösung noch auf sich warten lässt, aber die Wawi ist insgesamt auch ein komplexes Stück Software. Und vielleicht nicht ganz up-to-scratch, was man jetzt an den 5 Hotfixes nur für die neuen Masken+automatische Funktionsattribute für den JTL-Shop gesehen hat.

 

[John]

@NoOne Die Anforderungen an die bereitzustellenden Daten sind seit wann bekannt? 2022? 2023?
Du nimmst JTL in den Schutz, als seien die Rahmenbedingungen zur Umsetzung erst in den letzten 4 Wochen vom Himmel gefallen.
Für externe Schnittstellen mag das technisch stimmen, für eine saubere Datenhaltung in der Wawi und im eigenen JTL Shop nicht.

Saubere Datenhaltung bedeutet in der Datenbank atomare Daten und keine doppelten Datensätze. Damit kann man dann später auch beliebige, andere Schnittstellen bespielen, die zusammengesezte Daten erfordern.
Genau das hat JTL ja auch mit der neuen Verwaltung von Herstellerdaten und Verantwortlichen gemacht.

Aber wieso war das nicht bereits vor einem Jahr fertig in Wawi und Shop, sodaß jeder genügend Zeit zum Updaten und Pflegen hatte?

Dinge wie neues Lizenzsystem waren wichtiger.
Das Desaster mal wieder zeitlich absehbar.

 

[NoOne]

Das warum interessiert eigentlich überhaupt nicht, wenn Leute Terz machen, die sich selbst nicht seit 05/2023 darum gekümmert haben. Atomare Daten hin oder her, das hätte jedermann schon längst umgesetzt haben können. Gegenfrage lautet also: Warum wurde das nicht gemacht? Ich kanns nur immer wieder sagen: Es wäre nicht optimal gewesen, aber möglich. Und dann hätte niemand jetzt das Problem mit "Auf den letzten Drücker". Lösungen/Plugins von ServicePartnern gab es 2023 auch nicht. Also hat die Händler es zur Ankündigung im Mai wohl auch nicht gekümmert.

Das Desaster war zeitlich absehbar, weil es niemanden interessiert hat. Es *hatte jeder* Zeit zum Pflegen. Das ist die einfache Wahrheit dahinter. Da trifft JTL höchstens eine Teilschuld. Alle haben das auf den letzten Drücker umgesetzt. Auch Amazon, eBay und Co. Und zuletzt auch die Händler selbst. Zumindest für den JTL- Shop wär man eben auf gar keine Extralösung angewiesen gewesen. Nicht mal für die Datenblätter. Die kann man als Mediendateien oder Links in Artikelbeschreibungen oder extra Tabs anlegen.

Saubere Datenhaltung ist auch nur eine bequeme Ausrede, damit man es nicht selbst schuld ist, sondern mit dem Finger auf jemand anderen zeigen kann.

 

[John]

Sehe ich nicht so.

Das im Bereich GPSR etwas in der Wawi kommen mußte war klar.
Die Wawi ist nunmal der Ort der Datenhaltung und die Informationen irgendwo anders zu pflegen, macht in etwas genauso viel Sinn, wie die Artikelpreise nicht mehr in der Wawi pflegen zu wollen.

Ich finde es krass, wie viel "muss man sich selbst drum kümmern" bei den Gebühren, die JTL verlangt noch akzeptabel erscheinen.
Oder ist das ein Gewöhnungseffekt?
Gibt ja auch andere Klassiker in Sachen Daten, in den JTL einfach nicht hinne macht:
- HRB Eintrag in den eignen Firmendaten (als Folge man darf jeden Footer in Shop und Wawi manuell anpassen)
- Kundenfeld eMail für Rechnungsversand
- Packstation & Postnumer als Felder im Kundendatensatz
- Durchmesser in den Artikelmaßen

Alles kein Hexenwerk aber das Fehlen macht täglich massive Schmerzen.
Kann man das nicht mal einfach machen, statt neue Faxen?