Preis- und Aktionslogik ist die kommerzielle Regelschicht, die bestimmt, welchen Betrag ein Kunde zahlen soll, warum dieser Betrag gilt und wie der Shop das Ergebnis darstellt. Ein Produkt kann gleichzeitig einen Grundpreis, einen Aktionspreis, einen variantenspezifischen Preis, einen Preis für eine Kundengruppe, eine Mengenstaffel, einen Katalograbatt, einen Gutschein, einen Versandvorteil, eine Abonnementanpassung, einen Treuevorteil und eine steuer- oder regionsabhängige Preisbedingung besitzen. Im Storefront erscheint möglicherweise nur ein Endbetrag, doch dieser kann aus mehreren Datenobjekten und Berechnungsregeln entstehen.
Preisdaten liegen auf einer E-Commerce-Plattform nicht nur in einem Produktpreisfeld. Sie können über Produkt- und Variantendatensätze, Preislisten, Kundengruppen, Katalogregeln, Warenkorbregeln, Gutscheintabellen, Steuereinstellungen, Versandregeln, Währungskonfiguration, Abonnementsysteme, Loyalty-Apps, Enterprise-Preisengines, ERP-Integrationen oder benutzerdefinierte Erweiterungsdaten verteilt sein. Aktionslogik hängt noch stärker von ihrem Umfeld ab, weil ein Rabatt normalerweise Bedingungen für Berechtigung und Ausschlüsse, Zeiträume, Nutzungslimits, Prioritäten, Kombinationsregeln und eine Berechnungsreihenfolge benötigt.
Eine technische Prüfung muss daher klären, wo die kommerzielle Regel gespeichert ist, von welchen Daten sie abhängt, wie die Plattform sie berechnet und wie das Ergebnis in Warenkorb, Checkout, Bestelldaten, Reports, Rückerstattungen und Kundenkommunikation erscheint.
Was Preis- und Aktionslogik in einem E-Commerce-Shop darstellt
Preis- und Aktionslogik bildet das kommerzielle Entscheidungssystem des Shops. Sie beantwortet gleichzeitig, was ein Artikel normalerweise kostet, ob ein Kunde einen anderen Preis erhält, ob der Warenkorb für einen Rabatt qualifiziert ist, welche Produkte ausgeschlossen sind, ob der Versand betroffen ist, ob Steuern vor oder nach einem Rabatt berechnet werden und ob mehrere Vorteile kombiniert werden können.
Ein Shop kann für unterschiedliche Geschäftszwecke verschiedene Preisebenen verwenden:
| Preis- oder Aktionsebene | Was sie darstellt | Betroffene Shop-Funktion |
|---|---|---|
| Grundpreis | Normaler Verkaufspreis eines Produkts oder einer Variante | Produktseite, Warenkorbposition, Feeds, Reporting und Bestellsumme |
| Aktionspreis oder Vergleichspreis | Temporäre oder merchandisingbezogene Preisdifferenz | Sale-Kennzeichnung, durchgestrichene Preise, Kampagnenseiten und Conversion-Kommunikation |
| Variantenpreis | Unterschiedliche Preise für Größe, Farbe, Material, Bundle-Größe oder Konfiguration | Optionsauswahl, Warenkorbsumme, bestandsbezogener Kauf und Erwartungen an die Auftragsabwicklung |
| Kundengruppenpreis | Preis für Wholesale-, Retail-, VIP-, B2B-, Mitarbeiter- oder Mitgliedergruppen | Login-basierte Preise, Account-Preise, Segmentierung und Vertragsverkauf |
| Staffel- oder Mengenpreis | Preisänderung ab einer bestimmten Kaufmenge | Großmengen, Wholesale-Funktion, Preistabellen und Warenkorbberechnung |
| Katalogregel | Rabatt, der bereits vor dem Warenkorb greift | Kategorie-Merchandising, Produktlisting und Sichtbarkeit von Aktionen |
| Warenkorbregel | Rabatt aufgrund von Warenkorbkriterien | Gutscheine, Warenkorbsumme, Checkout-Anreize und Schwellenwertangebote |
| Versandvorteil | Kostenloser oder reduzierter Versand unter definierten Bedingungen | Checkout-Conversion, regionale Angebote und Margenkalkulation |
| Loyalty- oder Reward-Regel | Guthaben, Punkte, Mitgliederrabatt oder erworbener Vorteil | Kundenbindung, Account-Funktion und Wiederkaufsökonomie |
| Abonnement- oder wiederkehrender Preis | Preislogik für wiederkehrende Käufe oder Mitgliedschaftszyklen | Abrechnung, Verlängerung, Account-Verwaltung und Bestellautomatisierung |
| Externe Preisquelle | Preis aus ERP, POS, PIM, Marketplace oder Preisengine | Verwaltung der maßgeblichen Datenquelle, Synchronisierung und operative Governance |
Diese Ebenen können sich überschneiden. Ein Produkt kann gleichzeitig Aktionspreis, kundenspezifischen Preis, Kategorienaktion, Gutschein und Schwelle für kostenlosen Versand besitzen. Technisch entscheidend ist nicht nur, ob jede Ebene existiert, sondern welche Vorrang hat, welche kombiniert werden können und wie die Plattform das Endergebnis speichert.
Typische Datenstrukturen hinter Produktpreisen
Produktpreise beginnen meist mit einem Preisfeld, doch viele Shops benötigen mehr als einen Wert. Ein einfaches Produkt kann einen Grundpreis haben. Ein Variantenprodukt kann pro SKU einen eigenen Preis speichern. Marketplace-, B2B- oder internationale Shops können Preislisten nach Markt, Währung, Kundengruppe, Katalog, Vertrag oder Vertriebskanal führen.
Typische Preisfelder sind:
| Feld oder Eigenschaft | Typische Funktion | Technische Fragestellung |
|---|---|---|
| Product ID oder Variant ID | Verknüpft Preis mit verkaufbarem Artikel | Entscheidet, ob Preis für Stammprodukt oder einzelne Variante gilt |
| Grundpreis | Standardverkaufspreis | Kann auf einer Plattform produktbezogen und auf einer anderen variantenbezogen sein |
| Aktionspreis | Reduzierter aktiver Preis | Kann eigenen Zeitraum haben oder von Kampagnenregeln abhängen |
| Vergleichs- oder Listenpreis | Referenzpreis neben aktivem Preis | Kann Darstellung beeinflussen, ohne den berechneten Preis zu ändern |
| Kosten- oder Margenfeld | Interne Kostenbasis | Meist nicht kundenseitig, aber wichtig für Reporting und Margenprüfung |
| Währungscode | Währung des Preiswerts | Kann Preislisten, Wechselkursregeln oder marktspezifische Werte erfordern |
| Steuerklasse | Steuerkategorie des Produkts | Beeinflusst Steuerberechnung und regionale Compliance |
| Kundengruppen- oder Preislisten-ID | Berechtigungsbeziehung | Steuert B2B-, Wholesale-, Mitglieder- oder Vertragspreise |
| Mengenschwelle | Grenzwert für Staffelpreis | Legt fest, wann ein anderer Stückpreis gilt |
| Kanal- oder Marktbereich | Beziehung zu Storefront, Region, Marketplace oder Vertriebskanal | Bestimmt, welcher Preis im jeweiligen Verkaufskontext erscheint |
| Start- und Enddatum | Aktivierungszeitraum | Steuert Kampagnenzeitpunkt und Risiko veralteter Preise |
| Priorität oder Sortierung | Wert zur Konfliktauflösung | Bestimmt, welcher Preis oder welche Regel bei Überschneidung gewinnt |
Eine Plattform mit einem einzigen Produktpreis verhält sich deutlich anders als eine Plattform mit vielen Preiszeilen pro Produkt, Variante, Kundengruppe, Markt oder Kanal. Das beeinflusst Darstellung, Pflege, Export, Synchronisierung und Validierung.
Aktionsregeln als bedingungsabhängige Daten
Aktionsdatensätze enthalten üblicherweise einen Auslöser und eine Regel. Der Auslöser kann ein Gutscheincode, automatischer Rabatt, Kundensegment, Kampagnenzeitraum oder eine Warenkorbbedingung sein. Die Regel legt fest, was geschieht, wenn der Auslöser gültig ist.
Eine Aktionsregel kann viele Bedingungen enthalten:
| Bedingung | Beispiele | Was sich zwischen Plattformen ändern kann |
|---|---|---|
| Produktberechtigung | Bestimmte SKUs, Varianten, Kategorien, Kollektionen, Marken, Tags, Anbieter oder Attribute | Zielauswahl kann andere Objekttypen oder Abfragelogik verwenden |
| Ausschlüsse | Sale-Artikel, Restposten, Geschenkkarten, bestimmte Marken, Bundles, Abonnements oder Varianten | Ausschlüsse können eingeschränkt sein oder separate Regeln benötigen |
| Kundenberechtigung | Kundengruppen, Tags, Segmente, E-Mail-Domains, Mitgliedschaft, Loyalty-Level oder B2B-Account | Segmentierungsmodelle sind möglicherweise nicht direkt äquivalent |
| Warenkorbschwelle | Mindestumsatz, Mindestmenge, Höchstbetrag, Artikelanzahl oder Zwischensumme nach Ausschlüssen | Schwelle kann vor oder nach Rabatt, Steuer oder Versand berechnet werden |
| Rabattaktion | Prozent, fester Betrag, Buy-one-get-one, Gratisartikel, kostenloser Versand, Staffelangebot oder Bundle-Preis | Zielplattform unterstützt manche Aktionen nativ und andere nur über Apps |
| Nutzungslimit | Pro Kunde, Code, Bestellung, Lebenszeit oder Kampagne | Historische Nutzung lässt sich möglicherweise nicht gleich übertragen |
| Zeitraum | Start, Ende, geplante Kampagne, Zeitzone oder wiederkehrendes Fenster | Zeitverhalten kann von Plattformzeitzone und Scheduler abhängen |
| Kombinationsregel | Kombination mit Produkt-, Bestell-, Versandrabatten, Loyalty-Vorteilen oder manuellen Anpassungen | Rabattkombination ist häufig plattformspezifisch |
| Priorität | Welche Regel zuerst greift oder Konflikte gewinnt | Priorität kann explizit, implizit oder gar nicht verfügbar sein |
Ein Gutscheincode kann nach der Migration identisch aussehen und trotzdem anders funktionieren. Der Code ist nur die kundenseitige Kennung. Die Regelengine bestimmt Qualifikation, Ausschlüsse, Rabattbetrag, Kombination und Berechnung.
Berechnungsreihenfolge und Kombination von Rabatten
Die Berechnungsreihenfolge gehört zu den wichtigsten Plattformunterschieden. Zwei Shops können denselben Rabattbegriff verwenden und dennoch unterschiedliche Summen berechnen, wenn eine Plattform den Rabatt vor Steuern auf Positionen anwendet und eine andere nach weiteren Rabatten auf die Warenkorbzwischensumme.
Typische Fragen sind:
- Gilt der Rabatt für Produktposition, Warenkorbzwischensumme, Versand, steuerinklusive oder steuerexklusive Beträge?
- Ersetzt der Aktionspreis den Grundpreis, bevor ein Gutschein berechnet wird?
- Kann ein Gutschein auf einen bereits reduzierten Artikel angewendet werden?
- Dürfen Produkt- und Bestellrabatte kombiniert werden?
- Wird kostenloser Versand vor oder nach Auswahl der Versandart angewendet?
- Verteilt die Plattform einen Bestellrabatt anteilig auf Positionen?
- Bewahrt die Rückerstattungslogik die ursprüngliche Rabattverteilung?
- Rundet die Plattform pro Position, pro Steuerzeile oder erst die finale Bestellsumme?
Auch die Kombination mehrerer Rabatte ist besonders sensibel. Manche Plattformen erlauben mehrere automatische Rabatte und Gutscheincodes gleichzeitig. Andere erlauben nur einen Rabattcode, trennen Produkt- und Bestellrabatte, beschränken Kombinationen mit kostenlosem Versand oder benötigen Apps für komplexe Kombinationen. Ändern sich diese Regeln, kann eine Aktion zu großzügig, zu restriktiv oder wirtschaftlich anders werden, obwohl der sichtbare Rabattbetrag vertraut wirkt.
Wie sich Plattformmodelle unterscheiden
Plattformen unterscheiden sich darin, wie viel Preis- und Aktionslogik nativ, konfigurierbar, durch Erweiterungen oder durch externe Systeme gesteuert wird.
SaaS-Plattformen bieten häufig strukturierte Produkt- und Variantenpreise, Rabattcodes, automatische Rabatte, marktspezifische Preise und App-Erweiterungen. Das vereinfacht die Administration, kann aber Kombinationen, komplexe B2B-Preise, Regelprioritäten oder Kampagnenstrukturen begrenzen, sofern keine zusätzlichen Apps oder höherwertigen Funktionen eingesetzt werden.
Open-Source-Plattformen bieten oft tieferen Zugriff auf Katalogpreisregeln, Warenkorbpreisregeln, Kundengruppen, Steuerklassen und Erweiterungstabellen. Dadurch lässt sich komplexe kommerzielle Logik abbilden, doch Daten können über Kern-Tabellen, Module, benutzerdefinierte Attribute, serialisierte Konfiguration und eigenen Code verteilt sein. Eine sichtbare Aktion kann von mehreren erweiterungseigenen Datensätzen abhängen.
Enterprise-Plattformen können Preise in Preisbücher, gemeinsame Kataloge, Kundengruppen, Websites, Märkte, Verträge und Geschäftskonten aufteilen. B2B-Preise können von Account-Hierarchie, Unternehmensberechtigungen, Käuferrolle, verhandeltem Vertrag, Einkaufslisten oder ERP-Synchronisierung abhängen. Ein Produkt kann daher je nach Kunde und Kanal viele unterschiedliche kommerzielle Preise besitzen.
Bei Marketplace- oder Omnichannel-Shops ist die E-Commerce-Plattform möglicherweise nicht die einzige Preisquelle. Preise können aus ERP, POS, PIM, Marketplace-Tools, Repricing-Engines oder Channel-Managern übertragen werden. Die Shop-Plattform stellt und verarbeitet Preise dann zwar dar, die maßgebliche Datenquelle liegt jedoch außerhalb des Storefront-Systems.
Beziehungen zu anderen Shop-Daten
Preise und Aktionen hängen stark von umgebenden Shop-Strukturen ab. Eine Kategorienaktion benötigt Kategorie- oder Kollektionszuordnungen. Ein Kundengruppenpreis benötigt Kundengruppen oder Segmente. Ein Bundle-Rabatt hängt von Produktbeziehungen und Bestandslogik ab. Ein Abonnementrabatt hängt von wiederkehrender Abrechnung ab. Regionale Aktionen können Markt-, Währungs-, Versandzonen-, Steuer- oder Standortdaten benötigen.
Typische Abhängigkeiten sind:
| Abhängigkeit | Auswirkung auf Preis oder Aktion |
|---|---|
| Produkt- und Variantenstruktur | Bestimmt, ob Preis/Rabatt für Stammprodukt, SKU, Bundle, Kit oder konfigurierbare Auswahl gilt |
| Attribute und Tags | Können Berechtigung, Ausschlüsse, automatische Kollektionen, Sale-Seiten oder Labels steuern |
| Kategorien und Kollektionen | Steuern häufig Katalogregeln, Landingpage-Rabatte, Saisonaktionen und Merchandising-Gruppen |
| Kundengruppen und Segmente | Bestimmen B2B-, Wholesale-, Loyalty-, Mitglieder-, Mitarbeiter- oder VIP-Preise |
| Steuereinstellungen | Steuern Bruttopreise, Steuerklassen, regionale Berechnung und Rechnungssummen |
| Versandzonen und -arten | Steuern kostenlosen Versand, regionale Angebote, Schwellenwerte und Checkout-Anreize |
| Währungs- und Markteinstellungen | Steuern lokale Preise, Rundung, Darstellung und Wechselkursunterschiede |
| Bestand und Auftragsabwicklung | Können Bundle-Angebote, Backorder-Aktionen, Abonnementverfügbarkeit und regionale Verkäufe beeinflussen |
| Externe Systeme | Können Preise, Rabatte, Kundenberechtigung oder Bestellsummen überschreiben oder synchronisieren |
Eine Preisregel muss zusammen mit ihren Abhängigkeiten geprüft werden. Ändert sich das Variantenmodell, die Kategoriezuordnung oder wird eine Kundengruppe als Tag oder Segment neu aufgebaut, kann die Aktion neu interpretiert werden müssen, auch wenn der Regelname wiedererkennbar bleibt.
Plattformspezifische Funktionen und besondere Logik
Einige Preis- und Aktionsfunktionen existieren nicht auf jeder Plattform. Sie können nativ, App-/Erweiterungs-basiert, Enterprise-spezifisch oder extern synchronisiert sein.
Wichtige Beispiele sind:
- marktspezifische Preislisten und regionale Storefront-Preise;
- Kundengruppen- und B2B-Account-Preise;
- gemeinsame Kataloge und unternehmensspezifische Preisbücher;
- Wholesale-Mengenstaffeln;
- Abonnementrabatte und Regeln für wiederkehrende Bestellungen;
- Preisberechnung für Bundles, Kits und konfigurierbare Produkte;
- Einlösen von Loyalty-Punkten und Reward-Guthaben;
- Zusammenspiel mit Geschenkkarten und Store Credit;
- automatische Rabatte ohne Gutscheincode;
- Buy-one-get-one- und Gratisartikel-Aktionen;
- Preisrundung nach Währung, Markt, Steuerregel oder Zahlungsanbieter;
- ERP-gesteuerte Preise und vertragliche Account-Preise;
- Marketplace-Repricing und kanalspezifische Preise.
Diese Funktionen sind nicht austauschbar. Ein Kundengruppenpreis ist nicht zwingend dasselbe wie ein Rabatt auf Basis eines Kunden-Tags. Eine Katalogregel ist nicht immer einer Warenkorbregel gleichwertig. Ein Vergleichspreis ist nicht dasselbe wie ein zeitlich gesteuerter Aktionspreis. Ein von einer App berechneter Bundle-Preis ist nicht dasselbe wie ein nativer Variantenpreis. Um das beabsichtigte kommerzielle Ergebnis zu erhalten, muss klar sein, welche Plattformfunktion es ursprünglich erzeugt hat.
Was häufig fehlschlägt, wenn Preislogik falsch verstanden wird
Preisprobleme sind schwer zu erkennen, weil Admin-Daten korrekt aussehen können, während Storefront oder Checkout falsch rechnen.
| Fehlermuster | Wahrscheinliche Ursache | Auswirkung |
|---|---|---|
| Richtiger Gutscheincode, falscher Rabattbetrag | Regelaktion oder rabattfähige Zwischensumme hat sich geändert | Beschwerden, Kampagnenfehler, Margenverlust |
| Rabatt gilt für ausgeschlossene Produkte | Ausschlussmodell wurde nicht gleichwertig übertragen | Margenrisiko und Probleme mit Markenrichtlinien |
| Wholesale-Kunden sehen Retail-Preise | Kundengruppe oder Preislistenbeziehung hat sich geändert | B2B-Reibung und Supportaufwand |
| Sale-Kennzeichnung ohne vorgesehenen berechneten Preis | Darstellungs- und Aktivpreis sind getrennt gespeichert | Verwirrung und falsches Merchandising |
| Warenkorbsumme weicht ab | Berechnungsreihenfolge, Steuerbehandlung oder Rundung unterscheidet sich | Checkout-Abbruch, Buchhaltungsabweichung, komplexere Rückerstattung |
| Kostenloser Versand greift zu breit oder gar nicht | Versandregel, Zone, Schwelle oder Versandartbeziehung hat sich geändert | Margenverlust oder Conversion-Rückgang |
| Loyalty- oder Abonnementrabatt verschwindet | App-/extern gesteuerte Preislogik wurde nicht rekonstruiert | Bindungsverlust und Störung wiederkehrender Bestellungen |
| Mehrwährungspreise driften | Wechselkurs-, Marktpreis- oder Rundungslogik hat sich geändert | Regionale Preisinkonsistenz und Reporting-Probleme |
Diese Probleme sind strukturell. Ursache sind meist nicht äquivalente Plattformmodelle, nicht lediglich fehlende Bezeichnungen.
Preise und Aktionen vor der Migration prüfen
Eine gute Vorprüfung trennt Preiswerte von kommerzieller Logik. Der Preiswert ist die Zahl am Produkt oder an der Variante. Die kommerzielle Logik ist die Menge von Bedingungen, die entscheidet, ob sich dieser Wert ändert.
Händler sollten prüfen:
- Produkte und Varianten mit ungewöhnlichen Preisen;
- aktive Aktionspreise und geplante Kampagnenpreise;
- Kundengruppen-, Wholesale-, B2B- oder Mitgliederpreise;
- Staffel-, Mengen-, Abonnement- und Bundle-Preise;
- aktive Gutscheincodes und automatische Rabatte;
- Katalog- und Warenkorbregeln;
- Nutzungslimits, Zeiträume, Prioritäten und Kombinationsregeln;
- Abhängigkeiten von Produkt, Kategorie, Kunde, Region, Versand und Steuer;
- Preise aus Apps, Erweiterungen, ERP, POS, Loyalty-, Subscription- oder Marketplace-Systemen;
- historische Regeln, die besser eingestellt als übertragen werden sollten.
Die stärkste Prüfung beginnt mit wirtschaftlich wichtigen Szenarien statt mit jedem alten Gutschein. Aktive Launch-Angebote, B2B-Account-Preise, Loyalty-Rabatte, Abonnementpreise, margenkritische Ausschlüsse und Schwellen für kostenlosen Versand verdienen mehr Aufmerksamkeit als abgelaufene Saisonaktionen.
Auswirkungen auf die Migration
Preis- und Aktionsmigration sollte das beabsichtigte kommerzielle Ergebnis erhalten, soweit die Zielplattform es unterstützt. Manche Daten lassen sich als direkte Werte übertragen. Manche Regeln müssen in nativen Einstellungen der Zielplattform neu aufgebaut werden. Andere Funktionen benötigen App-Ersatz, Konfiguration, manuelle Einrichtung oder individuelle Behandlung, weil die Zielplattform ein anderes Preismodell nutzt.
Der wichtigste Punkt ist, Preise anhand realistischer Kunden- und Warenkorbszenarien zu validieren. Eine Regel darf nicht nur deshalb freigegeben werden, weil Gutscheincode oder Preiswert im Admin vorhanden sind.
Wichtige Szenarien sind:
- normales Retail-Produkt ohne Aktion;
- Variante mit anderem Preis als das Stammprodukt;
- Produkt mit Aktionspreis und Vergleichspreis;
- Kategorie- oder Kollektionsrabatt;
- Kundengruppen- oder B2B-Account-Preis;
- Mengenstaffel;
- Gutschein mit Ausschlüssen und Nutzungslimits;
- Warenkorb mit kombinierbaren oder nicht kombinierbaren Rabatten;
- Schwelle für kostenlosen Versand;
- steuerkritische Bestellung;
- Mehrwährungs- oder Regionalbestellung;
- Abonnement-, Bundle-, Loyalty- oder erweiterungsgesteuertes Preisszenario.
Wenn Preisregeln nicht durch direkte Zuordnung dargestellt werden können, muss die notwendige Behandlung getrennt nach Werttransformation, Beziehungszuordnung, selektiver Datensatzbehandlung, Zielkonfiguration oder angepasster Logik betrachtet werden. App-eigene Regeln, individuelle Preistabellen, externe Kennungen und eigene Berechnungen benötigen explizite Interpretation und Abnahmenachweise. Das bloße Verschieben gespeicherter Werte garantiert nicht, dass das ursprüngliche Verhalten entsteht.
Fazit
Preis- und Aktionslogik ist ein Datenarchitekturthema und nicht nur Marketing-Konfiguration. Sichtbarer Preis, Gutschein oder Rabattbezeichnung sind nur die Oberfläche eines Regelsystems, das Produkte, Varianten, Kategorien, Kunden, Steuern, Versandzonen, Währungen, externe Systeme und plattformspezifische Berechnungsreihenfolgen einbeziehen kann.
Vor der Migration muss geklärt werden, welche kommerziellen Ergebnisse nach dem Launch weiterhin korrekt sein müssen. Grundpreise, Aktionspreise, Kundengruppenpreise, Staffelpreise, Warenkorb- und Katalogregeln, Versandvorteile und erweiterungsgesteuerte Rabatte sollten anhand der Datenstrukturen und Plattformfunktionen geprüft werden, die sie erzeugen.
Bei komplexer Preislogik liefern repräsentative Warenkorbszenarien den belastbarsten Nachweis. Wenn eine Regel von nicht unterstützten Rabattstrukturen, App-/Erweiterungsdaten, externen Preisquellen oder nicht gleichwertigen Plattformfunktionen abhängt, muss die notwendige Behandlung vor der breiteren Ausführung geklärt werden.
Häufige Fragen
Warum kann dieselbe Aktion auf einer anderen Plattform anders funktionieren?
Eine Aktion wird durch mehr als ihren Namen oder Gutscheincode gesteuert. Berechtigungen, Ausschlüsse, Zwischensummenlogik, Steuerzeitpunkt, Versand, Rabattkombination, Priorität, Nutzungslimits und Rundung können sich zwischen Regelengines unterscheiden.
Was ist der Unterschied zwischen einem Produktpreis und einer Preisregel?
Ein Produktpreis ist ein gespeicherter Wert an Produkt, Variante, Preisliste oder Markt. Eine Preisregel bestimmt anhand von Kunde, Warenkorb, Produkt, Kategorie, Menge, Datum, Versand oder anderen Bedingungen, wann sich dieser Wert ändert oder ein zusätzlicher Rabatt gilt.
Sollten abgelaufene Aktionen migriert werden?
Nicht immer. Abgelaufene, veraltete, Test- oder wenig relevante Aktionen können oft eingestellt werden. Aktive Kampagnen, kundenspezifische Preise, Launch-Angebote, Wholesale-Preise, Loyalty-Regeln, Abonnementrabatte und margenkritische Ausschlüsse brauchen eine genauere Prüfung.
Wie sollte Preis- und Aktionslogik validiert werden?
Mit realistischen Kunden- und Warenkorbszenarien. Prüfen Sie produktspezifische Rabatte, ausgeschlossene Artikel, Kundengruppenpreise, Staffelpreise, kombinierte Rabatte, Schwellen für kostenlosen Versand, steuerkritische Summen, regionale Preise und erweiterungsgesteuerte Preislogik.
Wann braucht Preislogik individuelle Behandlung?
Wenn das erwartete Ergebnis von nicht unterstützter Regeltransformation, App-/Erweiterungsdaten, Loyalty-Logik, Abonnementpreisen, kundenspezifischen Preisbüchern, externen ERP-/POS-Preisen, komplexen Kombinationsregeln oder eigener Berechnungslogik abhängt, die die Zielplattform nicht direkt nachbilden kann.