Sortierung im Listing nach Preis = alle Preise 0 EUR

Kann mir mal jemand auf die Sprünge helfen, wie folgendes zustande kommt: Standardsortierung im Listing ist nach Beliebtheit. Wechselt man die Sortierung zu „niedrigster Preis“ oder „höchster Preis“, werden alle Preise mit 0 EUR angezeigt. Die Pseudopreise werden normal angezeigt. Stellt man zurück auf Beliebtheit, ist alles wieder korrekt. Habe keine Ahnung, wo ich anfangen soll, zu suchen.

Ist das Problem im Demoshop reproduzierbar? Habe es grade mal bei einem anderen Shop getestet und kann es nicht ganz nachvollziehen.

Ich hatte vor meinem Posting im Demoshop nachgesehen, aber da funktioniert es einwandfrei - soweit ich gesehen habe. Ich weiß halt nicht, wo ich anfangen soll und komme doch vom Hundersten zum Tausendsten. Die Preise sind in den anderen Sortiermodies korrekt, auf der Detailseite natürlich auch. Woher zieht der Shop die vorgegebenen Sortierungsfunktionen? Woher weiß der Shop, wenn ich {s name=‚ListingSortPriceLowest‘}{/s} auswähle, dass nach dem niedrigsten Preis sortiert werden soll? Habe gerade gesehen, dass seit dem Update von 3 auf 4 gar keine Impressions mehr gespeichert werden. Stimmt das? Oder macht unsere WaWi da irgend 'nen Quatsch?

Achja, und noch etwas wegen der Sortierung nach “Erscheinungsdatum”. Fürmich ist das Erscheinungsdatum das Datum, an dem der Artikel neu in den Shop gekommen ist. Bei uns sortiert er nach dem changetime. Das kann doch nicht korrekt sein, oder?

Hi ich hatte bei der Sortierung nach Preis exakt das gleiche Problem. Hat meine Agentur behoben, und die hat momentan leider Urlaub *hüstel*. Könnte die am Donnerstag mehr sagen Nutzt du evtl einen Connector für die Wawi und füllst das Feld Erscheinungsdatum in der DB mit der changetime aus der Wawi?

Falls sich bis Donnerstag nichts ergeben sollte, bin ich für einen Tip dankbar. :slight_smile: In s_articles gibt es die Spalte “datum”, die neu gefüllt wurde, als wir die Umstellung auf büro+ mit ShopConnect hatten. War nicht weiter schlimm - abgesehen davon, dass alle Artikel als “Neu” markiert wurden. Das Datum in “datum” bleibt nach jedem Upload unverändert. Was sich jedesmal ändert ist die Spalte “changetime”, wenn in der WaWi ein Artikel geändert wurde, bei dem die Änderung shoprelevant ist. In s_articles_details gibt es noch “releasedate”, aber da sind nach wie vor noch die ursprünglichen Daten drin und die werden auch nicht geändert.

Dann setzt du in Shopconnect einen Haken, dass das Feld nicht aktualisiert werden soll oder du lässt das Erstellungsdatum von B+ übertragen und nicht das zuletzt geändert Datum Das 0€ im Listing scheint ein Problem von SC4 zu sein. Hast du evtl. Varianten?

edit: Dann setzt du in Shopconnect einen Haken, dass das Feld nicht aktualisiert werden soll und lässt JETZT übertragen und nicht das zuletzt geändert Datum. Dann wird das Erscheinungsdatum in der DB gesetzt, wenn der der Artikel zum ersten Mal hochgeladen wird und dann nicht mehr. Die Anleitung von SC4 schlägt da ein paar Sachen vor, deren Sinn man erst im Livebetrieb erkennt und entsprechend anpassen muss. Das 0€ im Listing scheint ein Problem von SC4 zu sein. Hast du evtl. Varianten?

Jepps, wir haben Varianten, allerdings nicht das Variantenmodul in büro+. Da arbeiten wir mit einem Hauptartikel. Das das Änderungsdatum übertragen wird, ist ja nicht schlimm. Es wundert mich halt nur, dass der Shop auf “changetime” zugreift und nicht auf “datum”. Denn wie schon geschrieben, das Erstelldatum wird in “datum” übertragen und nicht mehr aktualisiert. Nuztz Du auch büro+ mit ShopConnect?

ich nutze auch diese Kombination, ja. Und ich könnte wetten, dass ein Feld in SC4 dafür verantwortlich ist. Echt schon alles doppelt geprüft? Gruß Euromann

Das das Datum der letzen Änderung eines Artikels übertragen wird, ist völlig okay. Es wird bei uns in s_articles > changetime eingetragen. So ändert sich z.B. auch das Datum in der Sitemap - was in der 3er Version nicht der Fall war. In s_articles > datum steht das Datum vom ersten Import in büro+, was ich aber ändern werde in das Datum, dass wir in den Selektionsfeldern haben, dass das ursprüngliche Erstelldatum ist. Mir geht es mehr darum zu erfahren, warum Shopware im wiki zu Sortierungsoptionen schreibt: a.datum < date_add(current_date, interval -5 day) Heisst für mich: a = s_articles datum = Spalte datum So hatte ich es bisher verstanden. Warum greift dann bei der Sortierungsfunktion “Erscheinungsdatum” (die ja im Standard vorhanden ist) nicht s_articles > datum, sondern s_articles > changetime ? In welcher Datei werden die 5 Sortierungsoptionen{s name=‘ListingSortRelease’}{/s}{s name=‘ListingSortRating’}{/s}{s name=‘ListingSortPriceLowest’}{/s}{s name=‘ListingSortPriceHighest’}{/s}{s name=‘ListingSortName’}{/s}gesteuert? Werden bei Dir in der Datenbank die Impressionen eines Artikels gezählt? Wenn ja, hast Du die Variantenerweiterung in büro+ ?

Moin und frohes Neues. :slight_smile: Habe gestern noch die Daten in s_articles.datum auf das ursprüngliche Erstellungsdatum geändert. In SC war das Erstelldatum von büro+ drin. Dadurch war bei allen Artikeln das identische Datum in der Shop-DB und somit hat der Shop auf s_articles.changetime zugegriffen. Seit der Änderung funtkioniert die Sortierung nach “Erscheinungsdatum”. Alle anderen funktionieren nicht, nicht mal die nach Artikelnummer. Habe mittlerweile auch den Code gefunden, in dem die vorgegebenen Sortierungsoptionen definiert werden. Was mir jetzt noch wichtig ist und ich hoffe, Du (Euromann) kannst mir die entsprechende Info geben: wenn Du Varianten im Shop hast, nutzt Du die Variantenerweiterung in büro+? Werden bei Dir die Impressionen eines Artikels in die Shopdatenbank geschrieben? Funktionieren die anderen Sortierungsoptionen bei Dir im Shop korrekt?

wenn Du Varianten im Shop hast, nutzt Du die Variantenerweiterung in büro+? ja Werden bei Dir die Impressionen eines Artikels in die Shopdatenbank geschrieben? früher ja, ich hab aber das komplette Berichtsgedöns von den Detailseiten geschmissen, von daher jetzt nicht mehr Funktionieren die anderen Sortierungsoptionen bei Dir im Shop korrekt? ja. Aber wie gesagt musste beim Sortieren nach Preis etwas angepasst werden, weil 0€-Preise angezeigt wurden

so, hier die Antwort meiner Agentur: [quote]das Problem stellt sich nur bei Attribut-Artikeln soweit ich mich erinnere. Abhilfe schafft, sich mal das Array des Artikels ausgeben zu lassen. In der dortigen Variable baseprice steht trotz Connector dann immer der richtige und sortable Preis, den man im Template dann ausgeben kann. Die Sortierung im Listing muss man per kleinem Hack in der sArticles.php anpassen, sodass das geht. [/quote] kann ich dir aber nicht mehr dazusagen…