FAQ – Produkt-Historie¶
PAngV¶
Ist das Plugin allein PAngV-konform – muss ich sonst nichts machen?
Das Plugin sorgt dafür, dass die technische Anzeige des 30-Tage-Tiefstpreises korrekt erfolgt. Die Werbung selbst (z.B. Banner, Newsletter, externe Anzeigen) musst Du immer noch korrekt formulieren. Das Plugin liefert das Datenfundament; die Rechtskonformität der konkreten Kampagne liegt bei Dir.
Was wenn ich gerade jetzt eine Aktion starte – warte ich erst 30 Tage?
Nein. Der 30-Tage-Tiefstpreis ist der niedrigste Preis IN den letzten 30 Tagen – nicht „seit 30 Tagen läuft das Plugin". Wenn der Preis in der relevanten Zeitspanne nie gesenkt wurde, ist der aktuelle Preis selbst der Tiefstpreis – dann gibt es nichts darzustellen.
Wenn Du das Plugin auf einem bestehenden Shop installierst, kannst Du via bin/console kommora:history:backfill --days=30 einen initialen Snapshot setzen, damit die History wenigstens einen Anker hat.
Variants: ein PAngV-Wert pro Variante oder Master?
Pro Variante. Wenn das Produkt 5 Varianten in 3 Größen hat, hat jede einzelne Variante ihren eigenen 30-Tage-Tiefstpreis – weil sich auch die Preise unabhängig ändern können.
Was wenn ich gar nicht mit Preisermäßigung werbe – brauche ich das Plugin trotzdem?
Strikt rechtlich nein – PAngV-Pflicht greift nur bei beworbenen Preisermäßigungen. Aber: - Audit-Log ist auch ohne PAngV wertvoll - Du gewinnst Backoffice-Effizienz bei Reklamationen - „Reduzierung" entsteht oft unbewusst (Sale, Coupon, Rabatt-Aktion) – dann brauchst Du es plötzlich doch
Audit-Log und Tracking¶
Werden auch Bulk-Imports getrackt?
Ja, sofern in der Konfig „Tracking auch bei Import" aktiv. Bei sehr großen Imports (>50.000 Datensätze) kann das die Import-Zeit messbar verlängern – Empfehlung: für initiale Migrations das Tracking temporär deaktivieren.
Werden Webhook-/API-Calls vom Lager-System getrackt?
Ja, sofern „Tracking auch bei API-Calls" aktiv. Quelle wird als api angezeigt, mit Integrations-User-Name wenn vorhanden.
Wer ist subscriber als Quelle?
Eine Änderung, die nicht von einem Web-Klick oder API-Call kommt, sondern aus einem anderen Plugin/Subscriber-Code (z.B. der Lager-Synchroniser eines anderen Plugins). Die genaue Quelle steht im Context-Data des Eintrags.
Welche Felder werden NICHT getrackt?
Standardmäßig nicht: hochfrequente Felder wie lastSeen, version, interne Update-Timestamps. Diese würden die History mit irrelevanten Einträgen fluten. Bei Bedarf in der Konfig aktivierbar.
Was passiert mit der History wenn ein Produkt gelöscht wird?
Die History-Einträge bleiben (mit product_id aber ohne Verlinkung). In der Liste werden sie als „Produkt entfernt" markiert. So bleibt der Audit-Trail erhalten.
Retention und Performance¶
Wie viel Speicher braucht die History bei einem mittleren Shop?
Faustregel: 10.000 Produkte × 5 Änderungen/Monat × 700 Bytes ≈ 35 MB/Monat = ~420 MB/Jahr. Mit Default-Retention 365 Tage also bei ~500 MB stabil.
Kann ich die Retention pro Feld unterschiedlich setzen?
Aktuell nein, nur globale Retention. Kommt mit nächster Version.
Was wenn ich die Retention runter setze – werden alte Einträge sofort gelöscht?
Beim nächsten wöchentlichen Cleanup-Run (sonntags 04:00) ja. Wenn Du sofort räumen willst: bin/console kommora:history:cleanup.
Rollback¶
Wie weit kann ich zurück-rollbacken?
Solange der History-Eintrag in der DB ist (= innerhalb der Retention). Ältere Einträge sind gelöscht und der Rollback nicht mehr möglich.
Was wenn der Datensatz inzwischen mehrfach geändert wurde – wird der Rollback dann ungültig?
Nein, Rollback funktioniert auch dann. Das Plugin setzt den Wert auf den Alt-Wert dieser konkreten History-Eintrags – unabhängig von den dazwischen liegenden Änderungen. Du springst also direkt auf den Stand „vor diesem Eintrag", egal ob dazwischen 3 oder 30 weitere Änderungen lagen.
Kann ich mehrere Rollbacks gleichzeitig machen?
Aktuell nicht im UI. Über die API geht es als Skript – pro Eintrag ein einzelner POST.
Erzeugt ein Rollback einen neuen History-Eintrag?
Ja. Damit auch der Rollback selbst nachvollziehbar ist (Quelle: „rollback").
Integration¶
Funktioniert das Plugin mit Variants und erweiterten Preisen?
Ja, beides. Variants haben ihre eigene History; erweiterte Preise (pro Sales-Channel/Kundengruppe) ebenfalls.
Funktioniert es mit dem Standard-Shopware-Import?
Ja. Der Standard-Import löst Subscriber aus, die das Plugin abfängt.
Funktioniert es mit B2B-Suite / SwagB2BPlatform?
Ja, sofern die Preise als reguläre Produktpreise (oder Sales-Channel-Preise) gespeichert sind. Spezielle B2B-Suite-Vertragspreise werden noch nicht getrackt – wird in einer Folgeversion ergänzt.
Custom Fields werden auch getrackt?
Ja, alle Custom-Field-Änderungen. Beim Eintrag siehst Du den Custom-Field-Technical-Name.
Datenschutz und Compliance¶
Werden User-Identifikatoren DSGVO-konform gespeichert?
Standardmäßig wird User-ID + Username gespeichert. Wenn Du strenge DSGVO-Vorgaben hast, kannst Du in der Konfig auf „nur User-ID" reduzieren. Bei cleanup werden auch ältere User-Daten anonymisiert.
Werden Kunden-Daten in der History gespeichert?
Nein, NUR Produkt-Änderungen. Keine Bestelldaten, keine Kundendaten.
→ Weiter mit Troubleshooting oder direkt zu support@kommora.de.