Neu 5.1.2 Strukturierte Daten, itemprop price

[golvreven]

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.

Zu 1.:
Wenn es nach DIN 1333 heißt:

• Ist die Ziffer an der ersten wegfallenden Dezimalstelle eine 0, 1, 2, 3 oder 4, dann wird abgerundet.
• Ist die Ziffer an der ersten wegfallenden Dezimalstelle eine 5, 6, 7, 8 oder 9, dann wird aufgerundet.

Dann bedeutet das für mich:
1. angezeigter Gesamtpreis im Shop (für Nutzer):
387,055 € -> angezeigter Gesamtpreis: 387,06 € ist korrekt

2. Gesamtpreis im Feed (für Google Shopping):
16,7227 * 19,45 * 1,19 = 387,0553 -> Gesamtpreis im Feed nach Rundung: 387,05 € ist nicht korrekt

3. Gesamtpreis im Markup (für Google):
19,9 € * 19,45 m² = 387,0550 € -> angezeigter Gesamtpreis nach Rundung: 387,05 € ist nicht korrekt

Welche Formel für das Markup verwendet wird, habe ich bereits geschrieben:
{($Artikel->fMindestbestellmenge*$Artikel->Preise->fVKBrutto)|string_format:"%.2f"}

Wie ich die "Abschneidung" beim Gesamtpreis im Feed verhindern kann, wüsste ich gerne. Gebe ich den Preis mit zwei Nachkommastellen an, kommt es entweder zur Abweichung vom angezeigten Gesamtpreis im Shop oder zur Abweichung vom Gesamtpreis im Markup.

 

[mvh]

Zu 1.:
Wenn es nach DIN 1333 heißt:

• Ist die Ziffer an der ersten wegfallenden Dezimalstelle eine 0, 1, 2, 3 oder 4, dann wird abgerundet.
• Ist die Ziffer an der ersten wegfallenden Dezimalstelle eine 5, 6, 7, 8 oder 9, dann wird aufgerundet.

Dann bedeutet das für mich:
1. angezeigter Gesamtpreis im Shop (für Nutzer):
387,055 € -> angezeigter Gesamtpreis: 387,06 € ist korrekt

2. Gesamtpreis im Feed (für Google Shopping):
16,7227 * 19,45 * 1,19 = 387,0553 -> Gesamtpreis im Feed nach Rundung: 387,05 € ist nicht korrekt

3. Gesamtpreis im Markup (für Google):
19,9 € * 19,45 m² = 387,0550 € -> angezeigter Gesamtpreis nach Rundung: 387,05 € ist nicht korrekt

Welche Formel für das Markup verwendet wird, habe ich bereits geschrieben:
{($Artikel->fMindestbestellmenge*$Artikel->Preise->fVKBrutto)|string_format:"%.2f"}

Wie ich die "Abschneidung" beim Gesamtpreis im Feed verhindern kann, wüsste ich gerne. Gebe ich den Preis mit zwei Nachkommastellen an, kommt es entweder zur Abweichung vom angezeigten Gesamtpreis im Shop oder zur Abweichung vom Gesamtpreis im Markup.

Ich habe den Wert 387,0553 mit mehreren Funktionen auf 2 Nachkommastellen gebracht, hier die Ergebnisse:

{387.0553|string_format:"%.2f"} = 387,06
{387.0553|round:2} = 387,06
{387.0553|round:2:PHP_ROUND_HALF_UP} = 387,06
{387.0553|round:2:PHP_ROUND_HALF_DOWN} = 387,05

Erklärung: string_format ist keine Rundung, sondern eine Konvertierung zu Zeichenfolge, das Ergebnis ist abhängig vom Wert und PHP-Version
round ist die echte Rundung, s. https://www.php.net/manual/de/function.round.php
PHP_ROUND_HALF_UP / PHP_ROUND_HALF_DOWN (ab PHP 5.3): Auf-/Abrundung bei der Hälfte (0,5)
Ich würde auf keinen Fall für die Rundung string_format verwenden. Für das Kaufmännische - round:2 oder mit PHP_ROUND_HALF_UP

 

[golvreven]

Ich habe den Wert 387,0553 mit mehreren Funktionen auf 2 Nachkommastellen gebracht, hier die Ergebnisse:

{387.0553|string_format:"%.2f"} = 387,06
{387.0553|round:2} = 387,06
{387.0553|round:2:PHP_ROUND_HALF_UP} = 387,06
{387.0553|round:2:PHP_ROUND_HALF_DOWN} = 387,05

Erklärung: string_format ist keine Rundung, sondern eine Konvertierung zu Zeichenfolge, das Ergebnis ist abhängig vom Wert und PHP-Version
round ist die echte Rundung, s. https://www.php.net/manual/de/function.round.php
PHP_ROUND_HALF_UP / PHP_ROUND_HALF_DOWN (ab PHP 5.3): Auf-/Abrundung bei der Hälfte (0,5)
Ich würde auf keinen Fall für die Rundung string_format verwenden. Für das Kaufmännische - round:2 oder mit PHP_ROUND_HALF_UP

Hallo mvh,

das sieht auf den ersten Blick super aus! Dass man das Auf- oder Abrunden erzwingen kann, wusste ich noch nicht. Ich habe es gleich ausprobiert mit:

<meta itemprop="price" content="{($Artikel->fMindestbestellmenge*$Artikel->Preise->fVKBrutto)|round:2:HP_ROUND_HALF_UP|string_format:"%.2f"}">
<meta itemprop="priceCurrency" content="EUR">

Die Konvertierung mit string_format brauchte ich, damit immer zwei Nachkommastellen angezeigt werden. Ich habe beim Test allerdings gleich einen Artikel gefunden, bei dem Folgendes passierte:

1. angezeigter Gesamtpreis im Shop (für Nutzer):
380,89 €

2. Gesamtpreis im Feed (für Google Shopping):
380,8944 €

3. Gesamtpreis im Markup (für Google):
380,90 €

Der Shop rechnet nämlich so: 15,9244 (Netto-VK) * 20,1 m² (Mindestabnahme) = 380,8957236 € (fVKBrutto). Im Feed bekomme ich durch die manuelle Eingabe von 380,8944 € (meinetwegen auch 380,8900 €) noch die Anpassung hin. Aber sowohl beim angezeigten Preis, als auch beim Markup nicht mehr, weil ich hier die Berechnung nicht beeinflussen kann. Beim Markup könnte ich in dem Fall das Abrunden erzwingen. Aber bei anderen Artikeln müsste ich wiederum das Aufrunden erzwingen.

Vielleicht fragst Du Dich, warum ich das Runden des angezeigten Preises nicht mit PHP_ROUND_HALF_UP erzwinge: {$Artikel->Preise->fVKBrutto|round:2:HP_ROUND_HALF_UP|string_format:"%.2f"} Ich habe es probiert - es tut sich nichts! Es gibt bei {$Artikel->Preise->fVKBrutto} offenbar keine Nachkommastellen, die auf- oder abgerundet werden können.

 

[mvh]

Hallo mvh,

das sieht auf den ersten Blick super aus! Dass man das Auf- oder Abrunden erzwingen kann, wusste ich noch nicht. Ich habe es gleich ausprobiert mit:

<meta itemprop="price" content="{($Artikel->fMindestbestellmenge*$Artikel->Preise->fVKBrutto)|round:2:HP_ROUND_HALF_UP|string_format:"%.2f"}">
<meta itemprop="priceCurrency" content="EUR">

Die Konvertierung mit string_format brauchte ich, damit immer zwei Nachkommastellen angezeigt werden. Ich habe beim Test allerdings gleich einen Artikel gefunden, bei dem Folgendes passierte:

1. angezeigter Gesamtpreis im Shop (für Nutzer):
380,89 €

2. Gesamtpreis im Feed (für Google Shopping):
380,8944 €

3. Gesamtpreis im Markup (für Google):
380,90 €

Der Shop rechnet nämlich so: 15,9244 (Netto-VK) * 20,1 m² (Mindestabnahme) = 380,8957236 € (fVKBrutto). Im Feed bekomme ich durch die manuelle Eingabe von 380,8944 € (meinetwegen auch 380,8900 €) noch die Anpassung hin. Aber sowohl beim angezeigten Preis, als auch beim Markup nicht mehr, weil ich hier die Berechnung nicht beeinflussen kann. Beim Markup könnte ich in dem Fall das Abrunden erzwingen. Aber bei anderen Artikeln müsste ich wiederum das Aufrunden erzwingen.

Warum nicht im Feed direkt auf 2 Stellen (immer) abrunden ?
Übrigens, wenn das JTL-Plugin für GS verwendet wird,
dann wird in "class.XML_GoogleShopping.inc.php" die JTL eigene Funktion berechneBrutto benutzt und diese rundet standartmäßig auf 2 Stellen:
function berechneBrutto($preis, $MwSt, $nGenauigkeit = 2)

 

[golvreven]

Warum nicht im Feed direkt auf 2 Stellen (immer) abrunden ?
Übrigens, wenn das JTL-Plugin für GS verwendet wird,
dann wird in "class.XML_GoogleShopping.inc.php" die JTL eigene Funktion berechneBrutto benutzt und diese rundet standartmäßig auf 2 Stellen:
function berechneBrutto($preis, $MwSt, $nGenauigkeit = 2)

Das besagte JTL-Plugin wird verwendet. Aber wie gesagt: Der Preis im Feed ist nicht mein Problem. Die Abweichung kommt ja im Shop zwischen dem angezeigten Gesamtpreis und dem Preis im Markup zu Stande. Den Preis im Feed kann ich nur an einen von beiden anpassen.

 

[webksde]

Hallo in die Runde,

wurde das Problem mittlerweile im Plugin seitens JTL gelöst?