Modules für Prestashop
Soziale netzwerkeWerbung & MarketingShop-FunktionalitätenWerkzeuge für das Admin-PanelBestellabwicklungssoftwareAnimierte Bild- und Inhalts-KarussellsZahlungSEO
IT-Dienstleistungen
Services bezüglich ModuleFehlerbehebung und ProblembehebungAdministration von Shop und HostingPrestashop-Modifikationen
Kontakt
PrestaShop Bedingte Bestellvalidierung
Die bedingte Bestellvalidierung sperrt oder warnt beim Checkout, wenn ein Warenkorb Ihre Regeln verletzt. Legen Sie Bedingungen für Produkte, Mengen, Summen, Kunden und Versand fest und zeigen Sie klare Gründe in Warenkorb und Kasse. Mit Simulator und Audit-Log testen Sie Richtlinien, bevor sie live greifen.
129.00 €
Galeria 1/12
PrestaShop Bestellregeln: Checkout Validierung & Blockierung
Dieses PrestaShop-Modul bietet eine Enterprise-Klasse-Lösung zur umfassenden Checkout-Regulierung. Es ermöglicht die Erstellung hochentwickelter visueller Richtlinien mit verschachtelten AND/OR-Bedingungsbäumen, die auf über 55 Feldern basieren, um unzulässige Bestellungen proaktiv zu blockieren oder gezielt davor zu warnen. Kunden erhalten transparente, mehrsprachige Begründungen direkt im Warenkorb und Checkout. Zu den Funktionen gehören ein Warenkorb-Simulator für risikofreie Tests, ein Analyse-Dashboard zur Leistungsüberwachung und ein vollständiges Audit-Protokoll für lückenlose Nachvollziehbarkeit jeder Entscheidung. Damit stoppen Sie effektiv inkompatible Artikel, gebrochene Mindestbestellmengen oder ungültige Versand-/Zahlungskombinationen, bevor sie zu Problemen werden.
Modulversion:
1.1.0
Shop-Versionen:
9.x8.x1.7.x
Funktioniert mit ThirtyBees:
Nein
Übersetzungen:
Blockieren Sie Bestellungen, die Ihre Regeln verletzen.
Visuelle Richtlinien. Klare Gründe. Vollständiges Audit.
PrestaShop akzeptiert bereitwillig jeden Warenkorb, solange noch Lagerbestand vorhanden ist - selbst wenn die Kombination für Ihr Geschäft unzulässig ist: inkompatible Artikel, gebrochene MOQ-Packs, Gastbestellungen über einem Limit, gesperrte Länder oder Zahlungsarten, die niemals zusammen versendet werden dürfen. Bedingte Bestellvalidierung ist eine Software der Enterprise-Klasse für die Checkout-Governance: visuelle Richtlinien, verschachtelte AND/OR-Bedingungsbäume mit unbegrenzter Gruppierung, Blockier- oder Warnaktionen, kundenseitig sichtbare Grund-Banner, Warenkorb-Simulator, Analyse-Dashboard und ein vollständiges Audit-Protokoll. Kombinieren Sie Bedingungen frei - verschachteln Sie Gruppen, verknüpfen Sie nebeneinanderliegende Elemente mit AND oder OR, stapeln Sie mehrere Regeln pro Richtlinie und mehrere Richtlinien pro Warenkorb - und in der Praxis erhalten Sie damit praktisch unbegrenzten Spielraum, um erweiterte Bestellregeln durchzusetzen. Kein Code. Keine Theme-Hacks. Eine Engine, die schlechte Warenkörbe stoppt, bevor sie zu schlechten Bestellungen werden.
Was Bedingte Bestellvalidierung leistet
Funktionen, die aus „hoffentlich lesen sie die FAQ" eine gesteuerte Checkout-Kontrolle machen. Gebaut als Software der Enterprise-Klasse für Shops, die echte Bestellregeln brauchen - nicht nur einen einzigen Mindestbestellwert. Die Stärke ist kombinatorisch: Gruppen, AND/OR-Verknüpfungen, Richtlinien und Regeln multiplizieren sich zu praktisch unbegrenzten Möglichkeiten.
Blockier- oder Warnrichtlinien
Harter Checkout-Stopp (Zahlungsoptionen filtern, Bestellabschluss sperren) oder sanfte Warnung mit einem klaren Banner. Benannte Richtlinien, Prioritätssortierung, Stopp bei erster Übereinstimmung, wenn sich Kampagnen nicht überlappen dürfen. Mehrere Regeln pro Richtlinie, jeweils mit eigenem Code, Aktion und mehrsprachiger Nachricht.
Andere: ein einziger globaler Mindestwarenkorbwert
Verschachtelter AND/OR-Bedingungsbuilder
55 Felder mit Drag-and-Drop-Gruppen. Jedes nebeneinanderliegende Element erhält seine eigene AND- oder OR-Verknüpfung - so ist (A AND B) OR C ein echter Baum, keine flache Liste. Unbegrenzte Verschachtelung für Merchandising-Logik, die dem tatsächlichen Denken von Ops-Teams entspricht.
Andere: hartkodierte Theme-Prüfungen
Verständliche Begründungen
Kunden sehen Ihre Nachricht plus eine nummerierte Grundliste mit Produktnamen und Beträgen in Fettdruck - identisch im Warenkorb und im Checkout. Eine unscharfe Deduplizierung hält die Liste übersichtlich, wenn mehrere Richtlinien greifen.
Andere: stiller Fehler oder vage Fehlermeldung
Warenkorb-Simulator
Wählen Sie einen echten Warenkorb und Kunden. Sehen Sie passende Richtlinien, Blockieren vs. Warnen, Regelcodes und exakte Nachrichten, bevor ein echter Käufer betroffen ist. Nutzt denselben Auswerter wie die Produktion.
Andere: in Produktion testen und beten
Analyse-Dashboard
KPI-Karten für Regelaufrufe, Checkout-Blockierungen und betroffene Bestellungen. Tägliche / wöchentliche / monatliche Chart.js-Trends und ein Kreisdiagramm nach Regelcode - damit das Merchandising sieht, was wirklich greift.
Andere: keine Sichtbarkeit nach der Einrichtung
Vollständiges Audit-Protokoll
Validierungsauswertungen, Blockierungen, Simulationen, Richtlinien-CRUD/Umschalten/Duplizieren/Import/Export und Einstellungsänderungen. Akteur, Warenkorb-ID, Regelcode, Aktion und JSON-Snapshot. Export über den vollständigen Audit-Controller.
Andere: Blackbox-Checkout
Import, Export, Duplizieren
Laden Sie jede Richtlinie als JSON herunter, spielen Sie sie in eine Staging-Umgebung ein, duplizieren Sie sie mit einem Klick. Verschieben Sie MOQ- und Inkompatibilitätsbäume zwischen Shops, ohne sie händisch neu aufzubauen.
Andere: jede Saison manuell neu aufbauen
Harter Zahlungsstopp
Bei Blockierung werden Zahlungsoptionen entleert und Front-JS-Sperren verhindern Weiter / Bestellung abschließen. Die serverseitige Validierung läuft trotzdem vor der Bestellerstellung - Verteidigung in der Tiefe.
Andere: nur Banner, die Bestellung geht trotzdem durch
Währungsbewusste Schwellenwerte
Betragsbedingungen werden in der Standardwährung konfiguriert und für die Auswertung und kundenseitige Begründungen in die Warenkorbwährung umgerechnet - konsistentes Multiwährungsverhalten.
Andere: Rohzahlen, falsche Währung
Bedingungen kombinieren. Gruppieren. Richtlinien stapeln.
Das ist nicht ein einziger Mindestbestellwert für den gesamten Shop. Es ist eine kombinatorische Validierungs-Engine - und genau das erschließt Enterprise-Checkout-Regeln, an die natives PrestaShop nicht heranreicht.
Bedingungen auf Bedingungen. Verschachtelte AND/OR-Bäume mit Verknüpfungen pro Nachbarelement - so ist (A AND B) OR C ausdrückbar. Unbegrenzte Tiefe für Merchandising-Logik.
Gruppen auf Gruppen. Jede Gruppe ist eine Klammer. Legen Sie MOQ-Regeln in eine Gruppe, Geo-Regeln in eine andere, verknüpfen Sie sie an der Wurzel mit OR - oder mit AND für strengere Tore.
Regeln auf Regeln. Mehrere Validierungsregeln pro Richtlinie: inkompatible Paare blockieren, bei geringem VIP-Umsatz warnen, Pack-Vielfache erzwingen - jeweils mit Code, Aktion und Nachricht.
Richtlinien auf Richtlinien. Mehrere aktive Richtlinien auf demselben Warenkorb. Prioritätssortierung. Stopp bei erster Übereinstimmung, wenn Sie Exklusivität benötigen. Andernfalls werden die Gründe in einem Banner zusammengeführt.
55 Bedingungsfelder x 14 Operatoren x unbegrenzt verschachtelte Gruppen x unbegrenzte Richtlinien und Regeln = in der Praxis praktisch unbegrenzte Möglichkeiten.
Verschachtelte AND/OR-Bedingungsbäume
Flache „wenn dies AND das"-Listen brechen in dem Moment, in dem das Merchandising echte Logik benötigt. Bedingte Bestellvalidierung speichert Bedingungen als Baum aus Gruppen, nicht als einzelne Checkliste. Jede Gruppe ist eine Klammer: Bedingungen und verschachtelte Gruppen darin werden zusammen ausgewertet. Zwischen jedem Nachbarelement - egal ob Blattbedingung oder eine weitere Gruppe - wählen Sie AND oder OR. Gruppen verschachteln sich ohne künstliche Tiefenbegrenzung, sodass Ausdrücke wie (Produkt A im Warenkorb AND Produkt B im Warenkorb) OR (Gastkunde AND Warenkorbsumme >= 200) vollwertig sind, keine Behelfslösungen.
So funktioniert die Gruppierung. Die Wurzelgruppe enthält die Logik der obersten Ebene. Fügen Sie Bedingungen als Blätter hinzu; fügen Sie eine verschachtelte Gruppe für eine neue Klammer hinzu. Ziehgriffe ordnen Nachbarelemente neu an oder verschieben Knoten zwischen Gruppen. Der Verknüpfungsselektor zwischen den Elementen schaltet AND/OR pro Kante um - Nachbarelement Nr. 2 kann per OR mit Nr. 3 verbunden sein, während Nr. 3 per AND mit Nr. 4 verbunden ist. Die Engine durchläuft den Baum rekursiv: Jede Gruppe reduziert sich zu wahr/falsch, dann kombinieren übergeordnete Verknüpfungen die Ergebnisse der Kinder.
AND vs. OR. AND bedeutet, dass jeder Operand erfüllt sein muss. OR bedeutet, dass mindestens einer erfüllt sein muss. Mischen Sie sie: Ein äußeres OR akzeptiert entweder einen VIP-Pfad oder einen Pfad mit hohem Umsatz; innere ANDs verschärfen jeden Zweig unabhängig.
Live-Neubewertung. Der Baum wird als strukturiertes JSON in der Richtlinie gespeichert und bei jeder Warenkorbänderung erneut geprüft - Produkt hinzufügen, Menge ändern, Anmelden, Adresse ändern, Spediteur oder Zahlung auswählen. Simulator und Front-Checkout nutzen denselben Auswerter.
Drei Logikmuster, die Sie visuell aufbauen können
Inkompatibles Paar
Baum: (Produkt 12 im Warenkorb AND Produkt 34 im Warenkorb). In einfachen Worten: Blockiert nur, wenn beide Artikel zusammen auftreten.
VIP oder hoher Umsatz
Baum: (Gruppe in VIP) OR (Warenkorbsumme >= 500 AND Angemeldet = Ja). Sanfte Warnung, außer bei VIP oder ernsthaftem Umsatz.
Geo + MOQ
Baum: (Lieferland not in EU) OR (Kategorie im Warenkorb AND Kategoriemenge Vielfaches von 6). Zwei Geschäftsregeln, eine Richtlinie.
AND/OR-Verknüpfungen pro Nachbarelement x unbegrenzte Verschachtelung x 55 Felder = boolesche Logik so ausdrucksstark wie eine Tabelle, so lesbar wie ein Flussdiagramm.
Gamechanger
Visuelles bedingtes Checkout-Tor - stoppen Sie schlechte Warenkörbe mit Gründen, die Kunden verstehen
Die meisten Shops behandeln Bestellregeln auf eine von drei mangelhaften Arten: eine FAQ, die niemand liest, ein Mindestbestellwert-Modul, das nur eine Zahl prüft, oder individuellen PHP-Code, der beim nächsten Update kaputtgeht. Keine davon kombiniert tief verschachteltes Targeting, klare Kundenkommunikation und auditierbare Durchsetzung an einem Ort.
Schritt 1 - WANN eingegriffen wird
Visueller Bedingungsbaum mit verschachtelten AND/OR-Gruppen: Produkte, MOQ-Vielfache, Summen, Gewicht, Gruppen, Gast/angemeldet, Land, Zone, Postleitzahl, Spediteur, Zahlung, Bestellverlauf, E-Mail-Domain, Tag/Stunde/Datum. Regeln greifen nur, wenn der Baum zutrifft.
Schritt 2 - WAS zu tun ist
Jede Regel wählt Blockieren oder Warnen, einen stabilen Regelcode für die Analyse, eine Priorität und eine mehrsprachige Nachricht. Die Engine fügt strukturierte Gründe mit fett hervorgehobenen Produktnamen und Mengen hinzu.
Schritt 3 - WIE Sie es belegen
Simulator auf echten Warenkörben. Dashboard-KPIs. Audit-Protokoll mit JSON-Snapshots. Zahlungsoptionen bei Blockierung entfernt - nicht nur ein rotes Kästchen.
Warum das wichtig ist: Sie hoffen nicht, dass Kunden Verpackungsregeln lesen, und Sie pflegen keine fragilen Theme-Überschreibungen. Sie betreiben eine Software der Enterprise-Klasse - eine bedingte Validierungs-Engine, in der sich Bedingungen mit AND/OR verschachteln, Aktionen blockieren oder warnen und jede Entscheidung simuliert, gemessen und auditiert werden kann.
20 Anwendungsfälle aus der Praxis
Jedes Beispiel ist eine Richtlinie, die Sie mit verschachtelten Gruppen aufbauen können. Blockieren Sie, wenn die Erfüllung unmöglich ist; warnen Sie, wenn Sie nur Aufklärung brauchen. Gründe werden im Warenkorb und im Checkout angezeigt.
1. Inkompatible Produktpaare
Bedrucktes T-Shirt AND Vektor-Download im selben Warenkorb (AND-Gruppe). Blockiert und listet beide Namen auf.
2. Packmengen-Vielfache (MOQ)
Produktmenge muss ein Vielfaches von 4 sein. Menge 3 blockiert mit einer klaren Begründung zur Packgröße.
3. Missbrauch von Gratisversand
(Versand = 0) AND (Warenkorbsumme < 50). Schützt Gratisversand-Schwellenwerte.
4. Ausgabenlimit für Gäste
Gast = Ja AND Warenkorbsumme >= 200. Erzwingt Anmeldung oder blockiert anonyme Warenkörbe mit hohem Wert.
5. Nur Lieferung innerhalb der EU
Lieferland not in EU-Liste. Blockiert nicht lieferbare Ziele frühzeitig.
6. Nachnahme für schwere Warenkörbe verboten
Zahlung = cashondelivery AND Gewicht >= 20. Verhindert Spediteur-Ablehnungen im Checkout.
7. Mindestmenge für Muster-Kategorie
Kategorie in Muster AND Kategoriemenge min. 3. Vermeidet Verschwendung durch einzelne Probepäckchen.
8. Markenexklusivität
Hersteller A im Warenkorb AND Hersteller B im Warenkorb. Vertragliche Exklusivität.
9. Missbrauch von Erstbestellungs-Gutscheinen
Erste Bestellung = Nein AND Gutschein angewendet. Schützt Akquisitionscodes.
10. Nur geschäftliche E-Mail (B2B)
Gruppe = B2B AND E-Mail-Domain not contains gmail. Hygiene für den Großhandelskanal.
11. Trennung virtuell + physisch
Has virtual AND Erfordert Versand. Vermeidet Albträume bei gemischter Auftragsabwicklung.
12. Stichtag für Personalisierung
Has customized AND Stunde >= 14. Warnt, dass die Gravur erst morgen versendet wird.
13. Postleitzahlen-Sperrliste
Postleitzahl-Regex / beginnt mit für abgelegene Inseln. Blockiert mit Kontakt-CTA.
14. Spediteur gegen Gewicht
Spediteur = Paketautomat AND Gewicht > 5. Kunde wechselt den Spediteur vor der Zahlung.
15. Neues Konto mit hohen Ausgaben
Kontoalter < 2 AND Summe >= 500. Stoppt ein klassisches Betrugsmuster.
16. Liefereinheiten des Lieferanten
Lieferantenmenge muss ein Vielfaches von N sein. Erzwingung von Dropship-Kartons.
17. Frische-Sperre am Wochenende
Frische-Kategorie AND Tag in [6,7]. Küche am Wochenende geschlossen.
18. Sanfter Hinweis für VIPs
VIP-Gruppe AND Produktsumme < 80 - nur Warnung, Checkout erlaubt.
19. Multistore-Geltungsbereich
Shop-ID = Outlet AND exklusives Produkt - Blockierung im Rabattkanal.
20. Sperre vor dem Launch
Produkt im Warenkorb AND Datum < Launch-Tag - blockiert Warenkörbe vor dem Launch.
Vollständiger Funktionsleitfaden
Referenz in einfacher Sprache für Shopbetreiber, Ops-Teams und Agenturen. Software der Enterprise-Klasse - tief genug für B2B- und Marketplace-Regeln, klar genug, dass alltägliche Richtlinienänderungen niemals einen Entwickler benötigen.
Richtlinien und Validierungsregeln
Eine Richtlinie ist eine benannte Kampagne mit einem Bedingungsbaum (WANN) und einer oder mehreren Validierungsregeln (WAS). Unbegrenzte Richtlinien, Positionssortierung, individuell aktivieren/pausieren. Jede Regel: Regelcode, Aktion (blockieren oder warnen), Priorität, mehrsprachige Nachricht.
Stopp bei erster Übereinstimmung endet nach der ersten qualifizierenden Richtlinie. Andernfalls tragen alle Übereinstimmungen Verstöße bei, nach Priorität sortiert, zu einem zusammengeführten Kundenbanner.
Visueller Bedingungsbuilder (Gruppen + AND/OR)
Drag-and-Drop-Baumeditor. Fügen Sie Bedingungen und verschachtelte Gruppen hinzu. Wählen Sie zwischen Nachbarelementen AND oder OR. So bauen Sie (MOQ AND Kategorie) OR (Geo-Einschränkung) ohne Code zu schreiben. SearchTool-Auswahlfelder für Produkte, Kategorien, Hersteller, Lieferanten, Gruppen, Spediteure und Währungen.
Die Enzyklopädie unten zeigt jedes Feld. Der Abschnitt Verschachtelte AND/OR-Bäume oben erklärt, wie Verknüpfungen und Klammern funktionieren.
Kundennachrichten, Banner und harte Stopps
Mehrsprachige individuelle Nachricht + strukturierte Grundliste. Ein Banner im Warenkorb und Checkout. Bei Blockierung: Zahlungsoptionen gefiltert, Bestellabschluss gesperrt, serverseitige Validierung vor der Bestellung läuft trotzdem.
Simulator, Dashboard und Audit
Der Simulator nutzt Live-Warenkörbe. Dashboard-KPIs + Chart.js. Das Audit-Protokoll zeichnet Validierungszustandsänderungen automatisch auf (nicht nur im Debug-Modus), zusätzlich zu Richtlinien-Lebenszyklusereignissen mit JSON-Snapshots.
Import / Export / Duplizieren / Vorlagen
Portable JSON-Richtlinien. Duplizieren mit einem Klick. Bedingungsvorlagen beschleunigen gängige Startpunkte (Gast, virtuell, Warenkorb mit hohem Wert, ...).
Jedes Bedingungsfeld - im Detail erklärt
Dies ist die vollständige Enzyklopädie der Felder, die im visuellen Bedingungsbuilder verfügbar sind. Jedes Feld kann alleine oder innerhalb verschachtelter AND/OR-Gruppen stehen. Geldschwellenwerte werden in der Standardwährung des Shops konfiguriert und zum Zeitpunkt der Auswertung und Anzeige in die Warenkorbwährung umgerechnet. Zusammengesetzte MOQ-Felder verwenden das Format id:schwellenwert.
Warenkorbbeträge und -größe
Warenkorbsumme (inkl. MwSt.)
Liest: Bruttowarenkorbsumme inklusive Steuer in der Warenkorbwährung des Kunden (Schwellenwert in Standardwährung gespeichert, zum Zeitpunkt der Auswertung umgerechnet).
Operatoren: =, !=, <, <=, >=, >, between
Wert: Dezimalbetrag in der Standardwährung des Shops, z. B. 50 oder Bereich 50;150 für between.
Beispiel: Blockiert, wenn Summe < 50, um Gratisversand-Aktionen zu schützen.
Varianten: Kombinieren Sie mit Gast = Ja für anonyme Obergrenzen mit hohem Wert; mit Hat Gutschein für Schutz vor Coupon-Missbrauch.
Produktsumme
Liest: Summe der Produktzeilen inkl. MwSt., ohne Versand.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Betrag in Standardwährung.
Beispiel: Warnt VIP-Gruppe, wenn Produktsumme < 80 (sanfter Hinweis auf Geschenkschwelle).
Varianten: Bevorzugen Sie dieses Feld gegenüber der Warenkorbsumme, wenn der Versand nicht in die Regel einfließen soll.
Produktsumme (exkl. MwSt.)
Liest: Netto-Produktzwischensumme (ohne Steuer).
Operatoren: =, !=, <, <=, >=, >, between
Wert: Betrag in Standardwährung.
Beispiel: B2B: erfordert Netto-Produktsumme >= 250 vor dem Checkout.
Varianten: Ideal für Großhandelsshops, die in Nettobeträgen denken.
Versandkosten
Liest: Aktueller Versandbetrag im Warenkorb.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Geldbetrag.
Beispiel: Blockiert, wenn Versand = 0 AND Produktsumme < 40 (Missbrauch von Gratisversand).
Varianten: Kombinieren Sie mit Ausgewählter Spediteur, um nicht passende Gratismethoden zu erkennen.
Gesamte Produktmenge
Liest: Summe der Mengen über alle Warenkorbzeilen.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Ganzzahl.
Beispiel: Warnt bei Menge > 100 wegen Betrugs- / Lagerrisiko.
Varianten: Nutzen Sie Eindeutige Produkte, wenn es Ihnen um Artikelvielfalt statt um Einheiten geht.
Eindeutige Produkte im Warenkorb
Liest: Anzahl unterschiedlicher Produktzeilen (Artikel).
Operatoren: =, !=, <, <=, >=, >, between
Wert: Ganzzahl.
Beispiel: Blockiert Musterpakete, außer wenn eindeutige Produkte >= 3.
Varianten: Gut für Sortimentsregeln unabhängig von Packgrößen.
Warenkorbgewicht (kg)
Liest: Gesamtgewicht des Warenkorbs in Kilogramm.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Dezimal-kg.
Beispiel: Blockiert Paketautomat-Spediteur bei Gewicht > 5.
Varianten: Kombinieren Sie mit Ausgewählter Spediteur OR Zahlungsmodul für Logistikgrenzen.
Anzahl der Warenkorbregeln
Liest: Wie viele Warenkorbregeln / Gutscheine derzeit angewendet werden.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Ganzzahl.
Beispiel: Blockiert Stapeln, wenn Anzahl der Warenkorbregeln > 1.
Varianten: Kombinieren Sie mit Warenkorb hat Gutschein für einfachere boolesche Prüfungen.
Warenkorb-Merkmale (boolesch)
Enthält mindestens ein virtuelles Produkt
Liest: Wahr, wenn sich ein virtuelles / herunterladbares Produkt im Warenkorb befindet.
Operatoren: =, != (Ja/Nein)
Wert: Boolesch Ja oder Nein.
Beispiel: Warnt, wenn eine Mischung aus virtuell + physisch Versand erfordert.
Varianten: Verwenden Sie zusammen mit Alle Produkte sind virtuell für reine Download-Warenkörbe.
Alle Produkte sind virtuell
Liest: Nur wahr, wenn jede Zeile virtuell ist.
Operatoren: =, !=
Wert: Boolesch.
Beispiel: Überspringt versandbezogene Blockierungen, wenn alle virtuell = Ja.
Varianten: Gegenteil von Hat physisches Produkt.
Hat physisches Produkt
Liest: Wahr, wenn mindestens ein versendbares Produkt existiert.
Operatoren: =, !=
Wert: Boolesch.
Beispiel: Erfordert einen Spediteur, wenn hat physisch = Ja.
Varianten: Kombinieren Sie mit Erfordert Versand für Erfüllungssperren.
Warenkorb erfordert Versand
Liest: PrestaShop-Kennzeichen: Warenkorb benötigt eine Lieferadresse / einen Spediteur.
Operatoren: =, !=
Wert: Boolesch.
Beispiel: Blockiert Zahlungsmodule, die nicht versenden können, wenn erfordert Versand = Ja.
Varianten: Nützlich für gemischte virtuell+physisch-Grenzfälle.
Hat personalisiertes Produkt
Liest: Wahr, wenn eine Produktpersonalisierung vorhanden ist.
Operatoren: =, !=
Wert: Boolesch.
Beispiel: Warnt nach 14:00 Uhr, dass die Gravur erst am nächsten Tag versendet wird.
Varianten: AND mit Tageszeit / Wochentag für Produktionsstichtage.
Warenkorb hat Gutschein angewendet
Liest: Wahr, wenn mindestens ein Rabatt / eine Warenkorbregel angewendet wird.
Operatoren: =, !=
Wert: Boolesch.
Beispiel: Blockiert Neukundengutscheine, wenn Erste Bestellung des Kunden = Nein.
Varianten: Einfachere Alternative zum Zählen von Warenkorbregeln.
Katalogpräsenz
Produkt im Warenkorb
Liest: Ob ausgewählte Produkt-ID(s) im Warenkorb erscheinen.
Operatoren: in, not in, =, !=
Wert: Eine oder mehrere Produkt-IDs über die SearchTool-Mehrfachauswahl.
Beispiel: in [T-Shirt, Vektor] mit AND aus zwei Produkt-Bedingungen - klassische Inkompatibilität.
Varianten: not in für Sperrlisten; kombinieren Sie mehrere Produkt-Blätter mit AND für Paare.
Kategorie im Warenkorb
Liest: Wahr, wenn ein Produkt zu ausgewählten Kategorie-ID(s) gehört.
Operatoren: in, not in, =, !=
Wert: Kategorie-IDs.
Beispiel: Kategorie Frischeprodukte im Warenkorb AND Wochenendtag - blockieren.
Varianten: Verschachtelte Kategorien hängen davon ab, wie Produkte im Katalog zugeordnet sind.
Hersteller im Warenkorb
Liest: Vorhandensein einer Marke / eines Herstellers.
Operatoren: in, not in, =, !=
Wert: Hersteller-IDs.
Beispiel: Marke A AND Marke B beide vorhanden - vertragliche Exklusivitätssperre.
Varianten: Verwenden Sie Herstellermenge für ein MOQ pro Marke.
Lieferant im Warenkorb
Liest: Vorhandensein eines Lieferanten (Dropship / Lager).
Operatoren: in, not in, =, !=
Wert: Lieferanten-IDs.
Beispiel: Lieferant X vorhanden - erzwingt Lieferantenmenge als Vielfaches der Kartongröße.
Varianten: Ideal für Marktplätze mit mehreren Lieferanten.
Mengen und MOQ (zusammengesetzt id:schwellenwert)
Produktmenge
Liest: Menge eines bestimmten Produkts im Vergleich zu einem Schwellenwert.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Zusammengesetzt productId:qty, z. B. 12:3.
Beispiel: Menge von Produkt 12 >= 3 für Mengenrabatt-Berechtigung (oder Blockierung unterhalb des MOQ).
Varianten: Bevorzugen Sie die dedizierten Min/Max/Vielfaches-Felder, wenn es um MOQ-Durchsetzung geht.
Kategoriemenge (Summe)
Liest: Summe der Mengen aller Zeilen in einer Kategorie.
Operatoren: =, !=, <, <=, >=, >, between
Wert: categoryId:qty
Beispiel: Summe der Kategorie Muster < 3 - warnt, mehr Muster hinzuzufügen.
Varianten: Funktioniert über mehrere Artikel derselben Kategorie hinweg.
Herstellermenge (Summe)
Liest: Mengensumme für einen Hersteller.
Operatoren: =, !=, <, <=, >=, >, between
Wert: manufacturerId:qty
Beispiel: Markenmenge > 50 - Betrugs- / Zuteilungswarnung.
Varianten: Gleiches Muster wie Kategoriesumme.
Lieferantenmenge (Summe)
Liest: Mengensumme für einen Lieferanten.
Operatoren: =, !=, <, <=, >=, >, between
Wert: supplierId:qty
Beispiel: Lieferanten-Kartonschwelle vor Zulassung des Checkouts.
Varianten: Kombinieren Sie mit Lieferantenmenge muss Vielfaches sein von.
Mindestmenge Produkt
Liest: Schlägt fehl, wenn die Produktmenge unter dem erforderlichen Minimum liegt.
Operatoren: Evaluator MOQ (min)
Wert: productId:minQty
Beispiel: Produkt 12 Minimum 4 - 1-3 Einheiten können nicht gekauft werden.
Varianten: Der Kundengrund zeigt das erforderliche Minimum an.
Höchstmenge Produkt
Liest: Schlägt fehl, wenn die Produktmenge das Maximum überschreitet.
Operatoren: Evaluator MOQ (max)
Wert: productId:maxQty
Beispiel: Begrenzung von 20 pro Artikel und Bestellung zur Zuteilungskontrolle.
Varianten: Nützlich für Launches und limitierte Editionen.
Mindestmenge Kategorie
Liest: Kategoriesumme muss mindestens N sein.
Operatoren: MOQ min
Wert: categoryId:minQty
Beispiel: Großhandelskategorie Minimum 12 Einheiten.
Varianten: Gilt für die Summe aller Produkte dieser Kategorie.
Höchstmenge Kategorie
Liest: Kategoriesumme darf N nicht überschreiten.
Operatoren: MOQ max
Wert: categoryId:maxQty
Beispiel: Begrenzt Aktionskategorie auf 6 pro Kundenbestellung.
Varianten: Kombinieren Sie mit Kundengruppe für B2C- gegen B2B-Grenzen.
Mindestmenge Hersteller
Liest: Herstellersumme >= N.
Operatoren: MOQ min
Wert: manufacturerId:minQty
Beispiel: Marken-Starterset erfordert 6 Einheiten.
Varianten: Gleiche Familie wie Kategorie-MOQ.
Höchstmenge Hersteller
Liest: Herstellersumme <= N.
Operatoren: MOQ max
Wert: manufacturerId:maxQty
Beispiel: Zuteilungsobergrenze von 30 Einheiten der Marke X pro Bestellung.
Varianten: OR mit Gast für strengere anonyme Grenzen.
Mindestmenge Lieferant
Liest: Lieferantensumme >= N.
Operatoren: MOQ min
Wert: supplierId:minQty
Beispiel: Mindestbestellmenge für einen Dropship-Partner.
Varianten: Verhindert unrentable Mikrobestellungen bei diesem Lieferanten.
Höchstmenge Lieferant
Liest: Lieferantensumme <= N.
Operatoren: MOQ max
Wert: supplierId:maxQty
Beispiel: Begrenzt riskante Lieferantenexposition pro Warenkorb.
Varianten: Betrugs- / Bonitätskontrollmuster.
Produktmenge muss Vielfaches sein von
Liest: Schlägt fehl, wenn die Produktmenge kein exaktes Vielfaches von N ist (Packgröße).
Operatoren: MOQ Vielfaches
Wert: productId:packSize z. B. 12:4
Beispiel: Pullover muss in Packs von 4 bestellt werden - Menge 3 blockiert mit klarer Begründung.
Varianten: Häufigste Großhandels-Packregel; die Begründung nennt aktuelle Menge und erforderliches Vielfaches.
Kategoriemenge muss Vielfaches sein von
Liest: Kategoriesumme muss ein Vielfaches von N sein.
Operatoren: MOQ Vielfaches
Wert: categoryId:packSize
Beispiel: Kategorie nur in Sechserpacks verkauft.
Varianten: Verwenden, wenn eine beliebige Mischung von Artikeln in der Kategorie trotzdem einen Karton füllen muss.
Herstellermenge muss Vielfaches sein von
Liest: Herstellersumme Vielfaches von N.
Operatoren: MOQ Vielfaches
Wert: manufacturerId:packSize
Beispiel: Markenkartongröße 12.
Varianten: Gleiche Semantik wie Kategorie-Vielfaches.
Lieferantenmenge muss Vielfaches sein von
Liest: Lieferantensumme Vielfaches von N.
Operatoren: MOQ Vielfaches
Wert: supplierId:packSize
Beispiel: Lieferant versendet nur volle Kartons zu 8 Stück.
Varianten: Erzwingung von Dropship-Kartons.
Produktzeilensumme
Liest: Monetäre Summe einer Produktzeile im Vergleich zu einem Schwellenwert.
Operatoren: =, !=, <, <=, >=, >, between
Wert: productId:amount
Beispiel: Zeilensumme von Produkt 12 < 20 - warnt vor unterbewerteter Konfiguration.
Varianten: Betrag wie andere Betragsfelder aus der Standardwährung umgerechnet.
Kunde
Kunde angemeldet
Liest: Ob die Sitzung einen authentifizierten Kunden hat.
Operatoren: =, !=
Wert: Ja / Nein.
Beispiel: Anmeldung erzwingen: Gastpfad blockiert, wenn Warenkorbsumme >= 200 AND angemeldet = Nein.
Varianten: Spiegelbild von Gastkunde.
Gastkunde
Liest: Wahr für Gast- / nicht angemeldeten Checkout.
Operatoren: =, !=
Wert: Ja / Nein.
Beispiel: Gast AND Warenkorb >= 200 - blockiert anonyme Bestellungen mit hohem Wert.
Varianten: Klassische Regel zur Betrugsreduktion.
Kundengruppe
Liest: Kunde gehört zu einer der ausgewählten PrestaShop-Gruppen.
Operatoren: in, not in, =, !=
Wert: Gruppen-IDs (VIP, B2B, Besucher...).
Beispiel: VIP-Gruppe - nur sanfte Warnung; Besucher - strenges MOQ.
Varianten: not in Besucher für Richtlinien nur für angemeldete Kunden.
Abgeschlossene Bestellungen des Kunden
Liest: Anzahl der historisch abgeschlossenen Bestellungen.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Ganzzahl.
Beispiel: Bestellungen = 0 mit Neukundengutschein - erlauben; Bestellungen > 0 - Gutscheinmissbrauch blockieren.
Varianten: Ergänzt den booleschen Wert Erste Bestellung des Kunden.
Lebenszeitausgaben des Kunden
Liest: Betrag der Lebenszeitausgaben (umgerechnet).
Operatoren: =, !=, <, <=, >=, >, between
Wert: Betrag in Standardwährung.
Beispiel: Lebenszeitausgaben >= 1000 schaltet nur Warnung statt Blockierung frei.
Varianten: Muster für Treue- / Vertrauensbewertung.
E-Mail-Domain des Kunden
Liest: E-Mail-Domain- / Adresszeichenfolge für Musterprüfungen.
Operatoren: =, !=, contains, starts with, regex, empty, not empty
Wert: Text oder Regex, z. B. @firma.de oder gmail.
Beispiel: B2B-Gruppe AND E-Mail not contains gmail - blockiert Verbraucher-E-Mails im Großhandel.
Varianten: regex für komplexe Erlaubnis-/Sperrlisten.
Erste Bestellung des Kunden
Liest: Wahr, wenn der Kunde keine früheren abgeschlossenen Bestellungen hat.
Operatoren: =, !=
Wert: Boolesch.
Beispiel: Erste Bestellung = Nein AND Gutschein angewendet - blockiert Akquisitionscodes bei Wiederholungskäufern.
Varianten: Klarer als orders_count = 0 für das Merchandising.
Kontoalter des Kunden (Tage)
Liest: Tage seit der Registrierung des Kunden.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Ganzzahl Tage.
Beispiel: Kontoalter < 2 AND Warenkorb >= 500 - blockiert (Betrugsmuster bei neuem Konto).
Varianten: between für Probezeit-Fenster.
Adresse, Versand, Zahlung, Shop
Lieferland
Liest: Land der Lieferadresse.
Operatoren: in, not in, =, !=
Wert: Länder-IDs / ISO-Auswahlliste.
Beispiel: not in EU-Länder - blockiert mit Geo-Nachricht.
Varianten: OR mit Rechnungsland für steuerliche Ansässigkeitsregeln.
Rechnungsland
Liest: Land der Rechnungsadresse.
Operatoren: in, not in, =, !=
Wert: Länder-IDs.
Beispiel: Rechnungsland != Lieferland - warnt vor Abweichung.
Varianten: B2B-USt-Szenarien.
Lieferzone
Liest: PrestaShop-Zone der Lieferadresse.
Operatoren: in, not in, =, !=
Wert: Zonen-IDs.
Beispiel: Zone = Inseln - blockiert Standardspediteure.
Varianten: Breiter gefasst als das Auflisten jedes Landes.
Lieferpostleitzahl
Liest: Postleitzahl-Zeichenfolge der Lieferung.
Operatoren: =, !=, contains, starts with, regex, empty, not empty
Wert: Text / Regex.
Beispiel: starts with 00- für Regeln der Hauptstadtregion; Regex für Inselbereiche.
Varianten: empty, um unvollständige Adressen zu erfassen.
Bundesland / Region der Lieferung
Liest: Bundesland / Region der Lieferadresse.
Operatoren: =, !=, in, not in, contains...
Wert: Bundesland-ID oder Text je nach Shop-Konfiguration.
Beispiel: Bundesland in [abgelegene Regionen] - blockieren oder Zuschlagswarnung.
Varianten: Nützlich für US-Bundesstaaten / kanadische Provinzen / spanische autonome Regionen.
Ausgewählter Spediteur
Liest: Für den Warenkorb gewählter Spediteur.
Operatoren: in, not in, =, !=
Wert: Spediteur-Referenz / ID über Auswahlfeld.
Beispiel: Spediteur = Paketautomat AND Gewicht > 5 - blockieren.
Varianten: Wird nach dem Spediteur-Schritt ausgewertet; erneute Prüfung bei Änderung.
Zahlungsmodul
Liest: Technischer Name des Zahlungsmoduls.
Operatoren: in, not in, =, !=
Wert: Modulname, z. B. ps_cashondelivery.
Beispiel: Nachnahme AND Gewicht >= 20 - blockieren.
Varianten: Funktioniert mit dem Zahlungsfilter bei globaler Blockierung.
Währung
Liest: Warenkorb-Währungs-ID.
Operatoren: in, not in, =, !=
Wert: Währungs-IDs.
Beispiel: Währung != Shop-Standard - warnt vor exotischen FX-Warenkörben.
Varianten: Geldschwellenwerte werden trotzdem umgerechnet; dies filtert nach Währungswahl.
Shop-ID
Liest: Aktuelle Shop-ID (Multistore).
Operatoren: =, !=, in, not in
Wert: Shop-ID als Ganzzahl.
Beispiel: Shop = Outlet AND exklusives Produkt im Warenkorb - blockieren.
Varianten: Hält Richtlinien bei Bedarf auf einen Shop begrenzt.
Zeitfenster
Wochentag (1-7)
Liest: Aktueller Wochentag in der Zeitzone des Shops (1 = Montag ... 7 = Sonntag).
Operatoren: =, !=, <, <=, >=, >, between, in
Wert: Ganzzahl 1-7 oder Liste für in.
Beispiel: in [6,7] AND Frische-Kategorie - blockiert Frischebestellungen am Wochenende.
Varianten: Kombinieren Sie mit Stunde für Freitag-Stichtage.
Tageszeit (0-23)
Liest: Aktuelle Stunde 0-23.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Ganzzahl-Stunde.
Beispiel: Stunde >= 14 AND personalisiertes Produkt - warnt vor Produktion am nächsten Tag.
Varianten: Fenster für Versand am selben Tag.
Datum (JJJJ-MM-TT)
Liest: Aktuelles Kalenderdatum.
Operatoren: =, !=, <, <=, >=, >, between
Wert: Datumszeichenfolge 2026-12-24 oder Bereich.
Beispiel: Datum < Launch-Tag AND Produkt im Warenkorb - blockiert Warenkörbe vor dem Launch über URL.
Varianten: Feiertags- / Kampagnenfenster ohne Cron-Jobs.
Statistiken für Nerds
Warenkorb ausgewertet. Bedingungen getroffen. Checkout blockiert oder gewarnt. Gründe angezeigt. Jede Entscheidung in Audit-Zeilen. Das ist Enterprise-Software - hier die Technik hinter dem Validierungs-Gate, auf das Ihr Kunde gerade gestoßen ist.
~26k
Codezeilen
PHP ~22k + JS ~2.2k + CSS ~1.2k + Smarty ~0.9k
103
Modul-Dateien
Klassen, Controller, Templates, SQL, Übersetzungen, Assets
55
Bedingungsfelder
Mit 14 Operatoren und verschachtelten AND/OR-Verknüpfungen
6
Backoffice-Reiter
Dashboard, Richtlinien, Einstellungen, Simulator, Audit-Protokoll, Updates
2
Aktionen
block_checkout und warn_checkout
17
Audit-Ereignisse
Validierung, Bestellungen, Richtlinien-/Regel-CRUD, Import/Export, Simulation, Einstellungen
15+
Hooks
Warenkorb, Checkout, Zahlungsfilter, Bestellvalidierung, Admin-Bestellung
32
Übersetzungen
Fertige Sprachpakete für BO- und FO-Texte
Datenbankschicht
-
6 individuelle Tabellen:
conordervalid_policy,conordervalid_rule,conordervalid_rule_lang,conordervalid_cart,conordervalid_preset,conordervalid_log. -
19 PHP-Klassen darunter Engine, ConditionTree, Context, Dashboard, AuditLog, Policy, Rule, CartState, ListRenderer, Admin.
-
Snapshots: violations-JSON pro Warenkorb; validation_snapshot-JSON auf Audit-Zeilen für die historische Wahrheit.
Architektur
-
Hooks: displayHeader, actionCartSave, actionFrontControllerInitAfter, actionFilterPaymentOptions, actionValidateOrder / Before, displayAdminOrder, Hooks zum Löschen von Warenkörben und mehr.
-
6 JS-Module: adminConditionBuilder, adminPolicyRules, adminConordervalidDashboard, adminConordervalidSimulator, adminConordervalidSearchTool, validation.js (Front-Banner).
-
PS-9-Kompatibilitätsschicht in
lib/prestashop9compatibility.php- eine einzige Codebasis für 1.7, 8 und 9. -
Chart.js im Dashboard für tägliche/wöchentliche/monatliche Trends und Kreisdiagramme nach Regelcode.
Chart.js
KPI-Trends und Kreisdiagramm-Aufschlüsselung nach Regelcode.
100+ Dateien
103 Dateien im vertreibbaren Modulpaket.
v1.1.0
Aktuelle Version für PrestaShop 9 / 8 / 1.7.
Bedingungen entscheiden, WANN eine Regel greift. Aktionen entscheiden, WAS passiert - blockieren oder warnen. Das Audit-Protokoll belegt, WARUM der Checkout so aussah.
~26.000 Codezeilen verteilt auf 103 Moduldateien, 32 Übersetzungspakete und v1.1.0. Das Merchandising baut den Baum. Die Engine setzt ihn durch. Der Support liest den Snapshot. Software der Enterprise-Klasse für die Checkout-Governance.
55 Bedingungsfelder, 14 Operatoren, 2 Durchsetzungsaktionen und eine einzige Audit-Spur - so konzipiert, dass eine Checkout-Blockierung nie ein Rätsel ist, sondern immer eine gemessene Geschäftsregel mit einem Grund, den der Kunde beheben kann.
Stoppen Sie schlechte Warenkörbe. Erklären Sie warum. Belegen Sie es im Audit-Protokoll.
55 Bedingungsfelder, verschachtelte AND/OR-Gruppen, 14 Operatoren, Blockier- und Warnaktionen, Simulator und vollständiges Audit - so konzipiert, dass eine Checkout-Blockierung nie ein Rätsel ist, sondern immer eine gemessene Geschäftsregel mit einem Grund, den der Kunde beheben kann.
129.00 €
Modulgalerie 1/12
Warum unser Modul wählen
Bedingte Bestellvalidierung?
Optimierung und Automatisierung
Das Modul "Bedingte Bestellvalidierung" optimiert und automatisiert Ihre Checkout-Governance mit Enterprise-Klasse-Regeln. Es blockiert unzulässige Bestellungen intelligent und liefert klare Gründe, was Ihre Betriebsabläufe erheblich vereinfacht.
Gesteigerter Umsatz
Mit "Bedingte Bestellvalidierung" steigern Sie den Umsatz, indem Sie Kunden durch transparente Regeln und präzise Meldungen zu gültigen Einkäufen führen. Dies verhindert unnötige Warenkorbabbrüche und stellt sicher, dass nur profitable Bestellungen durchgehen.
15 Jahre Erfahrung
Die „Bedingte Bestellvalidierung“ ist das Ergebnis von 15 Jahren PrestaShop-Erfahrung. Sie bietet eine enterprise-taugliche Engine für komplexe Bestellregeln mit nahtloser Kompatibilität von 1.7 bis 9, was tiefstes Plattformwissen beweist.
Umfangreiche Anpassung
Das Modul "Bedingte Bestellvalidierung" bietet umfangreiche Anpassungsmöglichkeiten durch 55 Bedingungsfelder und verschachtelte AND/OR-Gruppen. Gestalten Sie unbegrenzte, hochspezifische Bestellregeln präzise nach Ihren individuellen Anforderungen, um den Checkout Ihres Shops perfekt zu steuern.
Open Source Code
Der Modul "Bedingte Bestellvalidierung" bietet Ihnen vollständigen Zugriff auf den unverschlüsselten Quellcode (PHP, JS, CSS, Smarty). Dies ermöglicht umfassende Anpassungen, fortgeschrittene Integrationen und individuelle Erweiterungen, um Ihre Checkout-Regeln flexibel zu gestalten.
Lizenz und Updates
Die Lizenz für 'Bedingte Bestellvalidierung' bietet zeitlich unbegrenzte Nutzung zur sicheren Checkout-Kontrolle. Kostenlose Updates erhalten Sie ein Jahr lang; danach sichern Sie sich Aktualisierungen mit bis zu 90% Rabatt, um schlechte Bestellungen effektiv zu stoppen.