Zum Inhalt

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.