Neu 5.1.2 Strukturierte Daten, itemprop price

cashregisterstore

Sehr aktives Mitglied
29. September 2012
296
32
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

Moderator
Mitarbeiter
11. Oktober 2018
1.315
449
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.
Code:
<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

Gut bekanntes Mitglied
23. Januar 2010
144
11
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

1646949969174.png
 

MHillmann

Moderator
Mitarbeiter
11. Oktober 2018
1.315
449
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 :D
 

AMP-Agentur

Offizieller Servicepartner
SPBanner
19. Juli 2011
348
43
Magdeburg
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.
 

en001

Sehr aktives Mitglied
15. März 2017
444
43
Ein Beispiel zu deiner Aussage wäre ein Link zu einem Produkt mit Staffelpreis das abgeleht ist.
 

donc

Aktives Mitglied
13. November 2011
72
6
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
 
Zuletzt bearbeitet:

golvreven

Gut bekanntes Mitglied
1. Oktober 2020
217
18
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.
 

golvreven

Gut bekanntes Mitglied
1. Oktober 2020
217
18
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

Sehr aktives Mitglied
26. Oktober 2011
638
208
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.
 

bags

Aktives Mitglied
28. Januar 2014
55
1
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

Gut bekanntes Mitglied
1. Oktober 2020
217
18
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

Sehr aktives Mitglied
26. Oktober 2011
638
208
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.
 

Ähnliche Themen