Neu 5.1.2 Strukturierte Daten, itemprop price

[cashregisterstore]

In der aktuellen Shopversion scheint es ein Problem bei den strukturierten Daten zu geben. In der Version 5.1.1 wurde der Preis so dargestellt:
<meta itemprop="price" content="39.14">

In der neuen Version wird der Preis so dargestellt
<meta itemprop="price" content="39.1398">

Das Google Merchant Center schmeisst die Artikel nun raus, da der Wert laut Webseite nicht 39,14 EUR ist sondern 391398,00 EUR

Soweit ich das feststellen konnte betrifft das nur konfigurierbaren Artikel, Artikel mit Staffelpreisen und Artikel mit Variationskombinationen, es betrifft also nicht alle Artikel.

Vermutlich hat das mit dem Runden zu tun, hier wurde im letzten Beitrag dazu etwas geschrieben

https://forum.jtl-software.de/threa...-fmindestabnahme-kein-wert-ausgegeben.167349/

Es sieht so aus als dürften es nur 2 Nachkommastellen geben.

 

[MHillmann]

Hallo,

es gibt ein ähnliches Ticket in der 5.2.0 das diesen Fehler auch fixen sollte: https://issues.jtl-software.de/issues/SHOP-5500
Die Lösung hier: https://gitlab.com/jtl-software/jtl-shop/core/-/merge_requests/2437/diffs

Was du auch machen kannst: In der Template-Datei productdetails/price.tpl nach itemprop="price" suchen und überall wo es noch nicht gemacht ist ein |string_format:"%.2f" anhängen, z.B.

<meta itemprop="price" content="{if $Artikel->Preise->oPriceRange->isRange()}{$Artikel->Preise->oPriceRange->minBruttoPrice|string_format:"%.2f"}{else}{$Artikel->Preise->fVKBrutto|string_format:"%.2f"}{/if}">

Viele Grüße
Michael

 

[imperialo]

Hallo Michael,

danke für den Workaround - damit konnte ich meine gesperrten Produkte in Google wieder zum Leben erwecken Und auch bei mir waren es Produkte mit einem Konfigurator hinten dran.

Dann kann Ticket #2022022610000183 geschlossen werden.

Andere Frage - der maxPrice in den Konfiguratoren... ist das normal das der wirklich alle Produkte nimmt und diesen Wert einträgt? Siehe Bild:

Danke und viele Grüße

Impi

 

[cashregisterstore]

Tausend Dank

 

[MHillmann]

Bzgl. des "maxPrice": hast du eventuell nur optional einstellbare Konfigurationsgruppen und kann man eventuell auch beliebig viele Positionen in jeder Konfigurationsgruppe auswählen? Dann wäre wenn ich alles anhake das sicherlich auch der maximal mögliche Preis

 

[silent]

Bei mir wurden im Google Merchant Center alle Produkte deaktiviert, die einen Staffelpreis haben.

• Nicht übereinstimmender Wert (Seiten-Crawling) [Preis] – Aktualisieren Sie den Preis des Produkts in den Produktdaten, damit er mit dem Preis auf der Landingpage übereinstimmt

Es scheint das gleiche Problem zu sein, aber es braucht wohl eine andere Lösung, oder?

 

[AMP-Agentur]

Das sollte sich JTL dringend nochmal ansehen. Das betrifft sehr viele Shop Kunden. Fast alle Kunden, die wir von JTL-Shop 4 auf JTL-Shop 5 umgestellt haben, bekommen diese Fehlermeldungen von der Search Console.

 

[silent]

ich habe mal ein Ticket erstellt...

 

[en001]

Bei mir wurden im Google Merchant Center alle Produkte deaktiviert, die einen Staffelpreis haben.

Hast du mal ein Beispiel?

 

[silent]

wie meinst du das? Was für ein Beispiel?

 

[en001]

Ein Beispiel zu deiner Aussage wäre ein Link zu einem Produkt mit Staffelpreis das abgeleht ist.

 

[donc]

Wir haben das gleiche Problem, gibt es hier mittlerweile eine Lösung? Das kann doch nicht sein, es ist ein existenzielles Problem wenn bei uns alle Artikel abgelehnt werden.
Wie kann es denn überhaupt sein, dass trotz aktuellem Update sowas noch ausgeliefert wird? Shopping ist ja wohl für über 90% der ambitionierten Onlineshops essentiell

 

[golvreven]

Hallo zusammen,

anlässlich dieses Themas wollte ich mich erkundigen, ob es mittlerweile eine Lösung für das Rundungsproblem gibt? Dieses führt bei uns ständig zu einer kontinuierlichen Zahl von abgelehnten Artikeln im Google Merchant Center.

Viele Grüße
g.

 

[bags]

ich habe mal ein Ticket erstellt...

Wir schließen uns an und erstellen ebenfalls ein Ticket. Es kann ja wohl nicht sein, dass wir deswegen selbst in der template-Datei Hand anlegen müssen

 

[golvreven]

Hallo bags,

was würdet Ihr in "der template-Datei" ändern? Mein Problem ist, dass der Shop durch das Rundungsproblem abweichende Werte für folgende Formeln ausgibt, obwohl ich mit dem Taschenrechner auf dieselben Werte komme.

{$Artikel->Preise->fVKBrutto}
{($Artikel->fMindestbestellmenge*$Artikel->Preise->fVKBrutto)|string_format:"%.2f"}

Und da hilft aus meiner Sicht auch kein Eingriff in eine Template-Datei.

Viele Grüße
g.

 

[mvh]

Hallo bags,

was würdet Ihr in "der template-Datei" ändern? Mein Problem ist, dass der Shop durch das Rundungsproblem abweichende Werte für folgende Formeln ausgibt, obwohl ich mit dem Taschenrechner auf dieselben Werte komme.

{$Artikel->Preise->fVKBrutto}
{($Artikel->fMindestbestellmenge*$Artikel->Preise->fVKBrutto)|string_format:"%.2f"}

Und da hilft aus meiner Sicht auch kein Eingriff in eine Template-Datei.

Viele Grüße
g.

Hallo,
welche Rundungsprobleme meinst Du ? Du kannst auch fVKBrutto auf 2 Stellen runden.

 

[golvreven]

Hallo,
welche Rundungsprobleme meinst Du ? Du kannst auch fVKBrutto auf 2 Stellen runden.

Ich meine die Rundungsprobleme, von denen an vielen Stellen im Forum die Rede ist, beispielsweise in diesem Thread: https://forum.jtl-software.de/threads/rundungsdifferenzen.100765/

 

[bags]

Hallo bags,

was würdet Ihr in "der template-Datei" ändern? Mein Problem ist, dass der Shop durch das Rundungsproblem abweichende Werte für folgende Formeln ausgibt, obwohl ich mit dem Taschenrechner auf dieselben Werte komme.

{$Artikel->Preise->fVKBrutto}
{($Artikel->fMindestbestellmenge*$Artikel->Preise->fVKBrutto)|string_format:"%.2f"}

Und da hilft aus meiner Sicht auch kein Eingriff in eine Template-Datei.

Viele Grüße
g.

Servus, wir würden im template gar nichts ändern. Das bezieht sich nur auf einen Vorschlag weiter oben eines Moderators zu Änderungsmöglichkeiten im template.
Ich meinte damit eigentlich, es kann doch nicht sein, dass wenn derartige Fehler auftreten, die Kunden von JTL selbst hand anlegen müssen oder warten bis die Version 5.2 kommt 😌

 

[golvreven]

Hallo,
welche Rundungsprobleme meinst Du ? Du kannst auch fVKBrutto auf 2 Stellen runden.

Wie in dem verlinkten Thread von mir beschrieben, kann es zu Rundungsfehlern kommen, sobald der fVKBrutto als Formel ausgegeben wird:

1. angezeigter Gesamtpreis im Shop (für Nutzer):
Std. VK-Brutto * Mindestabnahme = Gesamtpreis -> angezeigter Gesamtpreis wird gerundet
19,9 € * 19,45 m² = 387,055 € -> angezeigter Gesamtpreis: 387,06 €

2. Gesamtpreis im Feed (für Google Shopping):
Std. VK-Netto * Mindestabnahme * Mehrwertsteuer = Gesamtpreis
16,7227 * 19,45 * 1,19 = 387,0553 -> Gesamtpreis im Feed nach Rundung: 387,05 €

3. Gesamtpreis im Markup (für Google):
Std. VK-Brutto * Mindestabnahme = Gesamtpreis -> angezeigter Gesamtpreis wird gerundet
19,9 € * 19,45 m² = 387,0550 € -> angezeigter Gesamtpreis nach Rundung: 387,05 €

Würde bei der Berechnung von 2. und 3. mit 5 als Nachkommastelle korrekt aufgerundet, wäre das alles kein Problem. Tatsächlich wird aber nicht aufgerundet.

Wenn ich den Gesamtpreis im Feed (für Google Shopping) manuell nur mit 2 Nachkommastellen hinterlege, heißt das nicht, dass ich damit den angezeigten Preis im Shop beeinflusse. Dann habe ich lediglich dafür gesorgt, dass der Gesamtpreis im Feed nicht falsch gerundet wird. Um den angezeigten Preis im Shop sauber zu bekommen, müsste ich entweder die Mindestabnahmemenge ändern - was praktisch nicht möglich ist, oder den Std. VK-Brutto so gestalten, dass es nicht zu dem Rundungsproblem beim fVKBrutto kommt. Ich sehe aber nicht ein, dass ich meine Preisgestaltung an einen Bug anpassen muss!

 

[mvh]

Wie in dem verlinkten Thread von mir beschrieben, kann es zu Rundungsfehlern kommen, sobald der fVKBrutto als Formel ausgegeben wird:

1. angezeigter Gesamtpreis im Shop (für Nutzer):
Std. VK-Brutto * Mindestabnahme = Gesamtpreis -> angezeigter Gesamtpreis wird gerundet
19,9 € * 19,45 m² = 387,055 € -> angezeigter Gesamtpreis: 387,06 €

2. Gesamtpreis im Feed (für Google Shopping):
Std. VK-Netto * Mindestabnahme * Mehrwertsteuer = Gesamtpreis
16,7227 * 19,45 * 1,19 = 387,0553 -> Gesamtpreis im Feed nach Rundung: 387,05 €

3. Gesamtpreis im Markup (für Google):
Std. VK-Brutto * Mindestabnahme = Gesamtpreis -> angezeigter Gesamtpreis wird gerundet
19,9 € * 19,45 m² = 387,0550 € -> angezeigter Gesamtpreis nach Rundung: 387,05 €

Würde bei der Berechnung von 2. und 3. mit 5 als Nachkommastelle korrekt aufgerundet, wäre das alles kein Problem. Tatsächlich wird aber nicht aufgerundet.

Wenn ich den Gesamtpreis im Feed (für Google Shopping) manuell nur mit 2 Nachkommastellen hinterlege, heißt das nicht, dass ich damit den angezeigten Preis im Shop beeinflusse. Dann habe ich lediglich dafür gesorgt, dass der Gesamtpreis im Feed nicht falsch gerundet wird. Um den angezeigten Preis im Shop sauber zu bekommen, müsste ich entweder die Mindestabnahmemenge ändern - was praktisch nicht möglich ist, oder den Std. VK-Brutto so gestalten, dass es nicht zu dem Rundungsproblem beim fVKBrutto kommt. Ich sehe aber nicht ein, dass ich meine Preisgestaltung an einen Bug anpassen muss!

Ich weiß nicht, welche Formeln im Feed/Markup verwendet werden, aber
1. Das ist die richtige kaufmännische Rundung (DIN 1333),
2. und 3. ist die "Abschneidung" keine Rundung, und in diesem Fall ist jeder Feed-Ersteller selbst dafür verantwortlich.
Werden mehr als benötigt Stellen übergeben - gibt es eine Warnung bzw. Google schneidet den Preis ab.
Im Feed (eigentlich auch im Shop-Template) entscheide ich und nicht JTL, wie ich die Daten vor-/ und nachbereite.