Catalog Price Rules vs. Cart Price Rules in Magento 2: Wann greift welche Regel?

1. Zwei Regelsysteme in Magento 2: Catalog Price Rules und Cart Price Rules im Überblick

Magento 2 bietet zwei getrennte Rabattmechanismen: Catalog Price Rules aus dem Modul Magento_CatalogRule und Cart Price Rules aus dem Modul Magento_SalesRule. Beide erzeugen Preisnachlässe, tun das aber auf grundlegend unterschiedliche Weise und zu unterschiedlichen Zeitpunkten. Catalog Price Rules verändern den angezeigten Produktpreis bereits im Katalog, bevor ein Kunde überhaupt etwas in den Warenkorb legt. Cart Price Rules greifen dagegen erst zur Laufzeit im Warenkorb oder Checkout und benötigen häufig einen Coupon-Code oder eine erfüllte Bedingung.

Der Modulname verrät bereits die Architektur: Magento_CatalogRule arbeitet mit einem eigenen Indexer, der Rabatte vorab berechnet und in einer eigenen Tabelle ablegt. Magento_SalesRule verzichtet dagegen komplett auf Indexierung und berechnet jede Regel live während der Preisberechnung im Quote-Objekt. Wer beide Systeme kennt, versteht sofort, warum ein Katalog-Rabatt sofort im Produktgrid sichtbar ist, ein Warenkorb-Rabatt aber erst nach dem Hinzufügen zum Warenkorb erscheint.

In der Praxis werden Catalog Price Rules und Cart Price Rules häufig verwechselt, weil beide im Admin-Panel unter "Marketing" gepflegt werden und ähnliche Bedingungs-Editoren nutzen. Die Bedingungen (Conditions) sehen im UI fast identisch aus, die zugrunde liegende Ausführung unterscheidet sich jedoch fundamental. Dieser Beitrag vergleicht beide Regelsysteme entlang von Indexierung, Datenmodell, Performance und Entscheidungslogik, damit die Wahl zwischen Catalog Price Rule und Cart Price Rule in jedem Projekt bewusst getroffen wird.

2. Catalog Price Rules im Detail: Indexierung, Anwendungszeitpunkt und Preisanzeige im Katalog

Eine Catalog Price Rule definiert eine Bedingung, etwa Kategorie, Attribut oder Kundengruppe, und eine Aktion: Prozent-Rabatt, fixer Betrag oder fixer Preis. Nach dem Speichern übernimmt der Indexer catalogrule_rule die Regel-Auflösung. Für jede Kombination aus Produkt, Kundengruppe, Website und Datum wird der resultierende Preis vorab berechnet. Das Ergebnis landet in der Tabelle catalogrule_product_price, aus der Produktlisten, Produktdetailseiten und der Preis-Index catalog_product_index_price ihre Werte beziehen. Der Kunde sieht den reduzierten Preis also bereits, bevor er das Produkt anklickt.

Diese Vorabberechnung hat einen entscheidenden Vorteil: Die Preisanzeige im Katalog kostet zur Laufzeit keine zusätzliche Rechenzeit, weil der Preis bereits im Index steht. Der Nachteil zeigt sich beim Speichern einer Regel oder bei Import-Läufen: Der catalogrule Indexer muss für alle betroffenen Produkt-Kundengruppen-Website-Kombinationen neu laufen, was bei großen Katalogen und vielen Kundengruppen mehrere Minuten dauern kann. Ohne rechtzeitigen Reindex zeigt der Katalog veraltete Preise, selbst wenn die Regel im Admin-Panel bereits aktiv ist.

Über die GraphQL-Schnittstelle erscheint der durch eine Catalog Price Rule reduzierte Preis im Feld final_price, während regular_price den unrabattierten Ausgangspreis liefert. Das Feld discount zeigt die Differenz beider Werte an, ohne dass der Client selbst rechnen muss. Da die Berechnung vollständig im Indexer stattfindet, liefert GraphQL denselben vorab berechneten Preis, den auch das Storefront-Grid anzeigt, konsistent über alle Zugriffspfade hinweg.

# GraphQL query showing catalog price already reduced by a Catalog Price Rule
query CatalogPriceExample {
  products(filter: { sku: { eq: "24-MB01" } }) {
    items {
      sku
      price_range {
        minimum_price {
          # Regular price without any Catalog Price Rule applied
          regular_price {
            value
            currency
          }
          # Final price already includes the active Catalog Price Rule
          final_price {
            value
            currency
          }
          discount {
            amount_off
            percent_off
          }
        }
      }
    }
  }
}

3. Cart Price Rules im Detail: Laufzeitberechnung im Checkout, Coupons und Kundengruppen-Bedingungen

Eine Cart Price Rule wird nicht vorab indexiert, sondern bei jeder Preisberechnung des Warenkorbs live ausgewertet. Sobald ein Kunde ein Produkt in den Warenkorb legt oder die Kasse betritt, prüft Magento alle aktiven Cart Price Rules gegen die aktuelle Quote: Kundengruppe, Warenkorbinhalt, Gesamtsumme, Versandart und gegebenenfalls einen eingegebenen Coupon-Code. Nur wenn alle Bedingungen zutreffen, wird die konfigurierte Aktion, etwa Prozent-Rabatt, fixer Betrag oder kostenloser Versand, angewendet.

Coupons sind eine Domäne, die ausschließlich Cart Price Rules abdecken. Catalog Price Rules kennen keinen Coupon-Mechanismus, weil sie bereits vor jeder Kundeninteraktion im Index feststehen. Cart Price Rules dagegen unterstützen sowohl automatische Regeln ohne Coupon als auch Regeln mit einem einzelnen festen Coupon-Code oder mit automatisch generierten Coupon-Sets für Kampagnen wie Newsletter-Anmeldungen oder Affiliate-Aktionen.

Kundengruppen-Bedingungen funktionieren bei Cart Price Rules feingranularer, weil zur Laufzeit der vollständige Kontext der Bestellung vorliegt: Rechnungsadresse, Versandland, bereits angewendete andere Regeln und die Reihenfolge, in der mehrere Cart Price Rules ausgewertet werden. Diese Laufzeitflexibilität erklärt, warum komplexe B2B-Sonderkonditionen, mengenabhängige Staffelrabatte oder zeitlich begrenzte Aktionscodes fast immer als Cart Price Rule und nicht als Catalog Price Rule umgesetzt werden.

4. Datenmodell-Unterschiede: catalogrule vs. salesrule Entity, Indexer-Architektur

Die Entity catalogrule liegt in den Tabellen catalogrule und catalogrule_website, während die Zuordnung zu Produkten in catalogrule_product materialisiert wird. Der eigentliche Preis pro Kombination steht in catalogrule_product_price, ergänzt um catalogrule_group_website, das die Gültigkeit pro Kundengruppe und Website abbildet. Diese Struktur ist bewusst denormalisiert, damit Lesezugriffe beim Rendern von Produktlisten ohne Joins über die Bedingungslogik erfolgen können.

Die Entity salesrule liegt dagegen in salesrule, salesrule_website, salesrule_customer_group und, sofern Coupons verwendet werden, in salesrule_coupon sowie salesrule_coupon_usage. Es gibt keine Preis-Tabelle, weil salesrule keine Preise vorab berechnet, sondern nur Regeldefinitionen und Bedingungen, serialisiert in salesrule.conditions_serialized, speichert. Die eigentliche Berechnung findet ausschließlich zur Laufzeit im Magento\SalesRule\Model\RulesApplier statt.

Die XML-Konfiguration in indexer.xml deklariert für Catalog Price Rules zwei Indexer: catalogrule_rule berechnet die Regel-Produkt-Zuordnung, catalogrule_product aktualisiert daraus abgeleitet den Produktindex. Cart Price Rules besitzen bewusst keinen Eintrag in indexer.xml, weil kein Index existiert, der invalidiert werden könnte. Diese architektonische Entscheidung ist der Kern des gesamten Unterschieds zwischen beiden Regelsystemen.

<?xml version="1.0"?>
<!-- Indexer declarations exist only for Catalog Price Rules, Cart Price Rules have none -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Indexer/etc/indexer.xsd">
    <indexer id="catalogrule_rule"
             view_id="catalogrule_rule"
             class="Magento\CatalogRule\Model\Indexer\IndexBuilder">
        <title translate="true">Catalog Rule Product Rules</title>
        <description translate="true">Rebuild the catalog rule to product mapping</description>
    </indexer>
    <indexer id="catalogrule_product"
             view_id="catalogrule_product"
             class="Magento\CatalogRule\Model\Indexer\Product\ProductRuleProcessor">
        <title translate="true">Catalog Rule Product</title>
        <description translate="true">Rebuild the catalog rule product price index</description>
    </indexer>
</config>

5. Wann welche Regel greift: ein Entscheidungsbaum für die Praxis

Die Entscheidung zwischen Catalog Price Rule und Cart Price Rule lässt sich anhand weniger Fragen treffen. Soll der Rabatt für alle berechtigten Kunden ohne eigenes Zutun sichtbar sein, sobald sie die Produktseite öffnen? Dann ist eine Catalog Price Rule richtig, etwa für einen dauerhaften B2B-Sonderpreis oder eine Rabattaktion, die bereits im Grid sichtbar sein soll. Braucht die Aktion dagegen einen Coupon-Code, eine Mindestbestellsumme oder eine Kombination aus mehreren Warenkorbpositionen? Dann ist eine Cart Price Rule das richtige Werkzeug, weil nur sie zur Laufzeit auf den vollständigen Warenkorbinhalt zugreifen kann.

Die folgende Tabelle fasst die wichtigsten Entscheidungskriterien zusammen. Wer eine Regel plant, sollte zuerst prüfen, ob der Rabatt bereits vor dem Hinzufügen zum Warenkorb sichtbar sein muss, denn genau das kann ausschließlich eine Catalog Price Rule leisten. Cart Price Rules eignen sich dagegen immer dann, wenn Coupons, Versandkosten oder warenkorbübergreifende Bedingungen, etwa "3 für 2", Teil der Aktion sind.

In gemischten Szenarien, etwa einem dauerhaften Sonderpreis für Wiederverkäufer kombiniert mit einer zeitlich begrenzten Newsletter-Aktion, kommen beide Regelsysteme parallel zum Einsatz. Der B2B-Sonderpreis läuft als Catalog Price Rule, die Newsletter-Aktion als coupon-basierte Cart Price Rule. Diese Kombination ist üblich und funktioniert zuverlässig, solange Reihenfolge und mögliche Überschneidungen beachtet werden, wie der nächste Abschnitt zeigt.

6. Kombination beider Regelsysteme und Konfliktvermeidung

Werden Catalog Price Rules und Cart Price Rules gleichzeitig auf dasselbe Produkt angewendet, addieren sich die Rabatte standardmäßig, wenn beide Regeln aktiv sind und ihre Bedingungen erfüllen. Ein Produkt mit zehn Prozent Catalog Price Rule und einem zusätzlichen Cart Price Rule Coupon über weitere zehn Prozent führt schnell zu einem Gesamtrabatt, der wirtschaftlich nicht beabsichtigt war. Die Option "Discard subsequent rules" in der Cart Price Rule verhindert, dass nachfolgende Cart Price Rules zusätzlich greifen, wirkt aber nicht auf bereits im Katalogpreis enthaltene Catalog Price Rule Rabatte.

Ein bewährtes Muster zur Konfliktvermeidung ist, Cart Price Rules so zu konfigurieren, dass die Berechnungsgrundlage explizit dokumentiert wird: Basiert der Coupon-Rabatt auf dem regulären Preis oder auf dem bereits durch die Catalog Price Rule reduzierten Preis? Magento verwendet standardmäßig den zum Zeitpunkt der Warenkorbberechnung gültigen Preis, der bereits alle aktiven Catalog Price Rules enthält. Ohne diese Kenntnis entstehen in Rabattaktionen häufig unerwartet hohe Nachlässe, die im Reporting erst spät auffallen.

Die Reihenfolge mehrerer Cart Price Rules bestimmt, welche Regel zuerst ausgewertet wird und ob "Discard subsequent rules" nachfolgende Regeln blockiert. Für Catalog Price Rules gilt eine eigene Priorität, die unabhängig von Cart Price Rules konfiguriert wird. Ein sauberes Namensschema und eine dokumentierte Priorisierung beider Regelsysteme im Team verhindert, dass neue Marketing-Aktionen unbeabsichtigt mit bestehenden Catalog Price Rules kollidieren.

7. Performance-Implikationen: Reindex-Kosten bei Catalog Rules vs. Runtime-Berechnung bei Cart Rules

Catalog Price Rules verlagern die Rechenlast auf den Indexer-Lauf, nicht auf den Seitenaufruf. Das bedeutet: Je mehr Kundengruppen, Websites und Produkte eine Catalog Price Rule betrifft, desto länger dauert der Reindex von catalogrule_rule und catalogrule_product. Bei großen B2B-Katalogen mit hunderten Kundengruppen kann ein einzelner Reindex-Lauf mehrere Minuten beanspruchen, insbesondere im Indexer-Modus "Update on Save", bei dem jede Speicherung sofort einen vollständigen Reindex auslöst.

Im Indexer-Modus "Update by Schedule" läuft der Reindex stattdessen über den Cron-Job indexer_reindex_all_invalid im Hintergrund, was Admin-Nutzer beim Speichern einer Regel nicht blockiert, aber eine Verzögerung bis zur sichtbaren Preisänderung im Katalog bedeutet. Für Projekte mit häufigen Preisänderungen ist "Update by Schedule" in Kombination mit einem eng getakteten Cron-Intervall die richtige Wahl, um Reindex-Spitzen abzufedern, ohne die sichtbare Aktualität zu stark zu verzögern.

Cart Price Rules verursachen dagegen keine Indexer-Kosten, weil keine Vorabberechnung stattfindet. Ihre Kosten entstehen stattdessen bei jeder einzelnen Warenkorb- und Checkout-Anfrage, wenn der RulesApplier alle aktiven Regeln gegen die aktuelle Quote prüft. Bei vielen gleichzeitig aktiven Cart Price Rules mit komplexen Bedingungen steigt die Antwortzeit des Checkouts messbar, weshalb inaktive oder abgelaufene Regeln konsequent deaktiviert statt nur zeitlich befristet werden sollten.

#!/usr/bin/env bash
# Reindex catalog price rules after a rule change or a reduced schedule window
bin/magento indexer:reindex catalogrule_rule
bin/magento indexer:reindex catalogrule_product

# Check indexer mode and pending status for both catalog rule indexers
bin/magento indexer:status catalogrule_rule
bin/magento indexer:status catalogrule_product

# Switch from schedule (cron) to realtime for immediate price updates while testing
bin/magento indexer:set-mode realtime catalogrule_rule catalogrule_product

# Note: Cart Price Rules have no indexer entry at all, there is nothing to reindex here

8. Programmatische Erstellung beider Regeltypen über Service Contracts

Beide Regelsysteme lassen sich über eigene Service Contracts programmatisch anlegen, was für Daten-Migrationen, Setup-Skripte oder automatisierte Kampagnen-Erstellung relevant ist. Für Catalog Price Rules steht \Magento\CatalogRule\Api\CatalogRuleRepositoryInterface bereit, für Cart Price Rules \Magento\SalesRule\Api\RuleRepositoryInterface. Beide Repositories folgen demselben Prinzip: Ein Data-Objekt wird über eine Factory erzeugt, mit den relevanten Eigenschaften befüllt und anschließend über die save()-Methode des Repositories persistiert.

<?php

declare(strict_types=1);

namespace Mironsoft\PriceRuleTools\Service;

use Magento\CatalogRule\Api\CatalogRuleRepositoryInterface;
use Magento\CatalogRule\Api\Data\RuleInterfaceFactory;
use Magento\Framework\Exception\LocalizedException;

/**
 * Creates a Catalog Price Rule programmatically via the Service Contract.
 */
class CatalogPriceRuleCreator
{
    /**
     * @param CatalogRuleRepositoryInterface $catalogRuleRepository Repository for persisting catalog rules
     * @param RuleInterfaceFactory $ruleFactory Factory for the catalog rule data object
     */
    public function __construct(
        private readonly CatalogRuleRepositoryInterface $catalogRuleRepository,
        private readonly RuleInterfaceFactory $ruleFactory,
    ) {
    }

    /**
     * Creates a ten percent Catalog Price Rule for a website and all customer groups.
     *
     * @param int $websiteId Website scope for the rule
     * @return int Persisted rule id
     * @throws LocalizedException
     */
    public function createTenPercentRule(int $websiteId): int
    {
        $rule = $this->ruleFactory->create();
        $rule->setName('Summer Sale Catalog Rule');
        $rule->setIsActive(true);
        $rule->setWebsiteIds([$websiteId]);
        $rule->setCustomerGroupIds([0, 1, 2, 3]);
        $rule->setSimpleAction('by_percent');
        $rule->setDiscountAmount(10);
        $rule->setStopRulesProcessing(false);

        $savedRule = $this->catalogRuleRepository->save($rule);

        return (int) $savedRule->getRuleId();
    }
}

Die save()-Methode löst bei Catalog Price Rules automatisch die Invalidierung des zugehörigen Indexers aus, sodass ein anschließender Reindex-Lauf, manuell oder per Cron, die neue Regel korrekt berücksichtigt. Bei Cart Price Rules entfällt dieser Schritt vollständig, weil keine Indexierung existiert, die invalidiert werden müsste.

<?php

declare(strict_types=1);

namespace Mironsoft\PriceRuleTools\Service;

use Magento\SalesRule\Api\RuleRepositoryInterface;
use Magento\SalesRule\Api\Data\RuleInterfaceFactory;
use Magento\Framework\Exception\LocalizedException;

/**
 * Creates a Cart Price Rule with a coupon code programmatically via the Service Contract.
 */
class CartPriceRuleCreator
{
    /**
     * @param RuleRepositoryInterface $ruleRepository Repository for persisting sales rules
     * @param RuleInterfaceFactory $ruleFactory Factory for the sales rule data object
     */
    public function __construct(
        private readonly RuleRepositoryInterface $ruleRepository,
        private readonly RuleInterfaceFactory $ruleFactory,
    ) {
    }

    /**
     * Creates a coupon based Cart Price Rule with a fixed discount amount.
     *
     * @param string $couponCode Coupon code required at checkout
     * @param array<int> $websiteIds Websites the rule is valid for
     * @return int Persisted rule id
     * @throws LocalizedException
     */
    public function createCouponRule(string $couponCode, array $websiteIds): int
    {
        $rule = $this->ruleFactory->create();
        $rule->setName('Newsletter Signup Coupon');
        $rule->setIsActive(true);
        $rule->setCouponType(\Magento\SalesRule\Model\Rule::COUPON_TYPE_SPECIFIC);
        $rule->setCouponCode($couponCode);
        $rule->setWebsiteIds($websiteIds);
        $rule->setCustomerGroupIds([0, 1, 2, 3]);
        $rule->setSimpleAction('cart_fixed');
        $rule->setDiscountAmount(15);
        $rule->setStopRulesProcessing(true);

        $savedRule = $this->ruleRepository->save($rule);

        return (int) $savedRule->getRuleId();
    }
}

Beide Beispiele nutzen Constructor Property Promotion nach PHP-8.4-Standard und verzichten bewusst auf direkte Model-Instanziierung zugunsten der Service Contracts. Das macht die Klassen testbar, entkoppelt von der konkreten ORM-Implementierung und kompatibel mit zukünftigen Magento-Versionen, die intern jederzeit die Model-Schicht austauschen können, ohne dass sich das Interface ändert.

9. Debugging: warum eine Regel nicht greift

Die häufigste Ursache, wenn eine Catalog Price Rule oder Cart Price Rule nicht greift, ist eine falsch gesetzte Website- oder Kundengruppen-Zuordnung. Eine Regel, die nur für Website 1 aktiviert ist, wirkt nicht auf Bestellungen über Website 2, selbst wenn Katalog und Kundengruppen identisch erscheinen. Ebenso häufig: Der Kunde ist als Gast unterwegs, also in der Kundengruppe "NOT LOGGED IN", die Regel ist aber nur für registrierte Kundengruppen aktiviert.

Bei Catalog Price Rules ist die zweithäufigste Ursache ein veralteter Index. Wenn der Indexer im Modus "Update by Schedule" läuft und der Cron nicht rechtzeitig ausgeführt wurde, zeigt der Katalog weiterhin den alten Preis, obwohl die Regel im Admin-Panel als aktiv markiert ist. Ein manueller Lauf von bin/magento indexer:reindex catalogrule_rule catalogrule_product und ein anschließender Cache-Flush schaffen in den meisten Fällen sofort Klarheit.

Bei Cart Price Rules liegt die Ursache oft im Zeitraum, also From/To Date, oder in der Priorität mehrerer Regeln: Eine höher priorisierte Regel mit "Discard subsequent rules" verhindert, dass eine später ausgewertete Regel überhaupt zur Anwendung kommt. Auch ein bereits verbrauchter Einmal-Coupon oder eine falsch gesetzte Nutzungsgrenze pro Kunde führt dazu, dass die Regel technisch aktiv ist, aber für den konkreten Kunden nicht mehr anwendbar. Ein Blick in salesrule_coupon_usage und in die Bedingungs-Konfiguration der Regel klärt die meisten Fälle innerhalb weniger Minuten.

10. Zusammenfassung

Catalog Price Rules und Cart Price Rules lösen in Magento 2 unterschiedliche Aufgaben und sollten nie als austauschbare Werkzeuge behandelt werden. Catalog Price Rules berechnen Rabatte vorab über einen Indexer, zeigen sie bereits im Katalog und kennen keine Coupons, dafür verursachen sie Reindex-Kosten bei jeder Änderung. Cart Price Rules berechnen Rabatte live zur Laufzeit im Warenkorb, unterstützen Coupons und komplexe Bedingungen, kosten dafür bei jeder Checkout-Anfrage Rechenzeit.

Der Entscheidungsbaum ist einfach: Muss der Rabatt bereits im Katalog sichtbar sein, ist eine Catalog Price Rule richtig. Braucht die Aktion einen Coupon, eine Mindestbestellsumme oder warenkorbübergreifende Bedingungen, ist eine Cart Price Rule das passende Werkzeug. Wer beide Regelsysteme bewusst kombiniert, die Reihenfolge dokumentiert und Indexer-Modi passend zum Änderungsrhythmus wählt, vermeidet doppelte Rabattierung und unnötige Performance-Kosten in Produktion.

11. FAQ: Catalog Price Rules vs. Cart Price Rules in Magento 2