> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dreizack-medien.de/llms.txt
> Use this file to discover all available pages before exploring further.
# Einstellungen
> Gutschrift, Einmal-Boni, Einlösung, Teilnahme und Integrität konfigurieren
## Gutschrift
Legt fest, wie Bonuspunkte beim Kauf vergeben werden.
Punkte pro Euro Warenwert.
Ob Punkte auf den Brutto- oder Nettopreis gerechnet werden (gilt für Gutschrift und Anzeige).
Wie Punktebeträge gerundet werden (gilt für Gutschrift und Anzeige): **Abrunden**, **Kaufmännisch runden** oder **Aufrunden**.
Fester Einlösewert eines Punktes.
Nur änderbar, solange keine Punkte im Umlauf sind (Restschuld = 0). Bereits ausgegebene Punkte würden sonst rückwirkend um- oder abgewertet. Wie großzügig das Programm ist, steuerst du über das Feld **Punkte je Euro**.
Wann gutgeschriebene Punkte wirksam werden.
**Sofort**: bei Bestelleingang. **Bei Zahlungseingang / Versand**: erst wenn bezahlt bzw. versandt. **Nach Widerrufsfrist**: bei Zahlung gutgeschrieben, aber erst nach der eingestellten Frist einlösbar (empfohlen, bilanzsicher).
Pending-Fenster, bevor Punkte einlösbar werden.
Diese Option ist nur sichtbar, wenn als Freigabezeitpunkt **Nach Widerrufsfrist** gewählt ist.
Für rabattierte Artikel (Sonderpreis) keine Punkte vergeben.
## Ausgeschlossene Artikel
Artikel, für die weder Punkte vergeben noch Punkte angezeigt werden, typischerweise Gutscheine.
JTL kennt keinen Artikeltyp "Gutschein". Der Ausschluss läuft deshalb über Kategorien und Artikelnummern. Zusätzlich wirkt weiterhin das Artikelattribut `dzm_bonus_excluded` aus der Wawi (Wert `1` oder `ja`), das ist der beste Weg, wenn die Pflege im Warenwirtschaftssystem stattfinden soll.
Alle Artikel dieser Kategorien sind ausgeschlossen, Unterkategorien inbegriffen.
Artikelnummer eintippen und mit Enter bestätigen. Genaue Schreibweise wie in der Wawi.
## Punkte-Verfall
Punkte laufen erst ihre Mindestgültigkeit und verfallen dann gesammelt zu einem festen Stichtag im Jahr. Eingelöst werden immer die ältesten Punkte zuerst, damit Kunden so wenig wie möglich verlieren.
Aus: Punkte sind unbegrenzt gültig.
Ohne eingerichteten Cronjob wird nichts ausgebucht und der Verfall bliebe wirkungslos. Lege ihn unter **Administration → System → Cron → Queue-Eintrag erstellen** an, Typ **DZM Bonus Plus: Punkte-Verfall**, Frequenz 24 Stunden.
So lange sind Punkte auf jeden Fall gültig, gerechnet ab dem Tag der Gutschrift. Danach verfallen sie zum nächsten Stichtag.
Der jährlich wiederkehrende Tag (Tag und Monat), an dem abgelaufene Punkte ausgebucht werden. Punkte sind bis einschließlich zu diesem Tag einlösbar.
Das Modell entspricht dem, was Kunden von großen Bonusprogrammen kennen: Nicht jeder Punkt hat sein eigenes Verfallsdatum, sondern es gibt einen gemeinsamen Stichtag pro Jahr. Ein Punkt verfällt zum ersten Stichtag, der nach seiner Mindestgültigkeit liegt – die tatsächliche Laufzeit ist damit immer mindestens so lang wie eingestellt, im Schnitt ein halbes Jahr länger. Bei einem Jahr Mindestgültigkeit und Stichtag 30.09. verfallen Punkte vom 01.01.2026 am 30.09.2027, Punkte vom 01.12.2026 aber erst am 30.09.2028.
Unter **Was das konkret bedeutet** zeigt dir das Backend live eine Vorschau mit der aktuellen Einstellung, anhand derer du das Ergebnis für unterschiedliche Buchungsdaten nachvollziehen kannst.
Gilt nur für Punkte, die es beim Einschalten des Verfalls schon gibt: Sie verfallen frühestens zum ersten Stichtag nach dieser Frist, auch wenn sie rechnerisch längst abgelaufen wären.
Beim Einschalten bekommen alle Bestandspunkte ein Verfallsdatum – frühestens jedoch nach dieser Schutzfrist, damit niemand über Nacht sein Guthaben verliert. Das Datum wird pro Gutschrift beim Buchen eingefroren: Eine spätere Änderung von Frist oder Stichtag wirkt nur auf neue Punkte, nie rückwirkend.
Benachrichtigt Kunden rechtzeitig, wie viele Punkte wann verfallen.
Die Mail geht nur an Kunden, die zum jeweiligen Stichtag tatsächlich noch offene Punkte haben – bereits eingelöste Punkte werden nicht angekündigt. Jede Stufe wird pro Kunde und Stichtag genau einmal verschickt, auch wenn der Cronjob mehrmals täglich läuft.
Wann vor dem Stichtag erinnert wird. Mehrere Stufen möglich, jede Stufe wird einmal verschickt.
Ist die zugehörige E-Mail-Vorlage deaktiviert, geht keine Erinnerung raus. JTL markiert die Vorlage automatisch als fehlerhaft, wenn der Shop mehr Sprachen hat, als die Vorlage mitbringt. Text, Betreff und Aktivierung bearbeitest du unter **Administration → E-Mail → Vorlagen → Plugin-Vorlagen** in der Vorlage "Bonuspunkte verfallen bald". Anpassungen an der Vorlage überstehen ein Plugin-Update.
## Einmal-Boni
Punkte für einmalige Aktionen (0 = deaktiviert).
Punkte-Bonus bei Registrierung eines neuen Kunden.
Punkte-Bonus bei der ersten Bestellung eines Kunden.
Punkte-Bonus bei Double-Opt-in-Freischaltung des Newsletters.
## Einlösung
Regeln für das Einlösen von Punkten im Checkout.
Maximaler Anteil des Bestellwerts, der per Punkten bezahlt werden darf.
Punkte, ab denen eingelöst werden darf (0 = keine).
Einzulösende Punkte müssen ein Vielfaches davon sein.
## Checkout-Box
Wo die Einlöse-Box im Checkout erscheint.
**Automatisch:** erkennt NOVA/NIUplus selbst und fügt die Box an der passenden Stelle ein (empfohlen). **Custom:** an frei wählbarer Stelle.
**Bootstrap:** gewachsenes Nova-Markup mit Karten- und Grid-Klassen. **Neutral:** templatefreies BEM-Markup ohne Grid- und Karten-Klassen, für eigene oder fremde Templates.
**Optionen:**
* **Bootstrap (Nova/NIUplus)**
* **Neutral (templatefrei, BEM)**
Die beiden Einstellungen sind unabhängig: Du kannst neutrales Markup auch am vorgesehenen Anker ausspielen, nicht nur an einem eigenen Selektor. Der neutrale Skin bringt nur eine schlanke Grundgestaltung mit, gedacht ist er zum Selberstylen über die BEM-Klasse `dzm-bonus-redeem`.
CSS-Selektor des Zielelements, an dem die Einlöse-Box eingefügt wird (z. B. `#order-confirm`).
Nur relevant, wenn bei **Platzierung** die Option **Custom – eigener Selektor** gewählt ist.
Wie relativ zum Zielelement eingefügt wird.
**Optionen:**
* **Davor (before):** Fügt die Box vor dem Element ein.
* **Danach (after):** Fügt die Box nach dem Element ein.
* **Als erstes Kind (prepend):** Fügt die Box als erstes Kindelement in das Element ein.
* **Als letztes Kind (append):** Fügt die Box als letztes Kindelement in das Element ein.
## Teilnahme
Teilnahme am Bonusprogramm.
Leer = alle Kundengruppen nehmen teil. Sonst sammeln und sehen nur Kunden der ausgewählten Gruppen Punkte.
Zur Auswahl stehen die in deinem Shop angelegten Kundengruppen (z. B. Endkunden, B2B, Händler).
Standard: aus. Alle registrierten Kunden nehmen automatisch teil (Programm in der Datenschutzerklärung abdecken). An: Kunden müssen bei der Registrierung über eine Checkbox zustimmen, bevor Punkte verarbeitet werden.
Für ein rein shop-internes Punkteprogramm ist eine separate Einwilligung meist nicht zwingend, ein Hinweis in Datenschutzerklärung/AGB genügt. Nötig wird sie, wenn Daten an Dritte fließen oder du den dokumentierten Consent-Nachweis (mit Logging) willst. Bei aktiver Pflicht brauchst du die Teilnahme-Checkbox.
Zustimmungs-Checkbox bei der Registrierung (Anzeigeort Registrierung, mit DSGVO-Logging). Nach dem Anlegen frei in der JTL-Checkboxverwaltung anpassbar (Text, Pflicht, Kundengruppen).
Sobald die Checkbox angelegt ist, zeigt das Feld **Angelegt** an.
## Kundenkonto-Bilanz
Wo die Punktebilanz im Kundenkonto des Kunden erscheint.
**Automatisch:** erkennt Nova/NIUplus selbst und wählt den passenden Anker (empfohlen). **Nova:** zusätzliche Karte auf der Konto-Übersicht. **NIUplus:** eigener Tab in der Konto-Navigation. **Custom:** an frei wählbarer Stelle.
**Bootstrap:** gewachsenes Nova-Markup mit Karten- und Grid-Klassen, passt in Nova und NIUplus. **Neutral:** templatefreies BEM-Markup ohne Grid- und Karten-Klassen, für eigene oder fremde Templates.
**Optionen:**
* **Bootstrap (Nova/NIUplus)**
* **Neutral (templatefrei, BEM)**
Die beiden Einstellungen sind unabhängig: Du kannst neutrales Markup auch an den vorgesehenen Ankern ausspielen, nicht nur an einem eigenen Selektor. Der neutrale Skin bringt nur eine schlanke Grundgestaltung mit, gedacht ist er zum Selberstylen über die BEM-Klassen `dzm-bonus-account` beziehungsweise `dzm-bonus-redeem`.
CSS-Selektor des Zielelements, an dem die Bilanz eingefügt wird (z. B. `#mein-konto`).
Nur relevant, wenn bei **Platzierung** die Option **Custom – eigener Selektor** gewählt ist.
Wie relativ zum Zielelement eingefügt wird.
**Optionen:**
* **Davor (before):** Fügt die Bilanz vor dem Element ein.
* **Danach (after):** Fügt die Bilanz nach dem Element ein.
* **Als erstes Kind (prepend):** Fügt die Bilanz als erstes Kindelement in das Element ein.
* **Als letztes Kind (append):** Fügt die Bilanz als letztes Kindelement in das Element ein.
## Checkout-Hinweise
Kurze Punkte-Hinweise im Warenkorb, Checkout und auf der Bestellbestätigung.
Zeigt im Checkout die erzielbaren Punkte und auf der Danke-Seite "Du hast X Punkte erhalten" (inkl. Hinweis, wann sie gutgeschrieben werden).
Weist Kunden mit Guthaben darauf hin, dass sie Punkte am Ende des Checkouts einlösen können.
## Testmodus
Das Programm im Live-Shop erproben, ohne dass Kunden etwas davon merken.
An: Kunden sehen keine Punkte und sammeln keine. Sichtbar ist alles nur für im Backend angemeldete Admins.
Die Sichtbarkeit hängt an der Session – öffne den Shop aus dem Backend heraus (Link "Shop ansehen"), damit deine Frontend-Session als Admin erkannt wird. Ein direkt aufgerufener Shop-Tab zählt nicht.
Kundennummern, die im Testmodus wirklich Punkte sammeln und einlösen dürfen. Leer = niemand sammelt, reine Vorschau.
Gebucht wird ausschließlich für die hier eingetragenen Testkunden. Bleibt die Liste leer, ist der Testmodus eine reine Vorschau – es entsteht keine Punkteschuld in der Bilanz.
## Integrität & Sicherheit
Der Integritätsschlüssel (HMAC) sichert die Revisionssicherheit der Punktebuchungen gegen nachträgliche Manipulation.
**Zero-Config aktiv:** Der Integritätsschlüssel wird standardmäßig aus dem `BLOWFISH_KEY` abgeleitet, kein Setup nötig.
Wird der `BLOWFISH_KEY` rotiert (z. B. über `dzm_blowfish_rekey`), ist die bestehende Hash-Kette nicht mehr verifizierbar, denn der alte Schlüssel lässt sich nicht reproduzieren. Für maximale Revisionssicherheit setze einen eigenen Schlüssel.
Empfehlung: einen eigenen HMAC-Schlüssel setzen (überlebt eine BLOWFISH-Rotation). Schlüssel generieren, die zwei Zeilen in `includes/config.JTL-Shop.ini.php` einfügen (in der Regel per FTP, da die Datei meist nicht beschreibbar ist), dann den Shop-Cache leeren.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.