GutscheinWerk: Eine Sperre darf einen vorhandenen Restwert nicht verschwinden lassen

Nicht einlösbar ist nicht dasselbe wie verbraucht

Ein Gutschein wird vorübergehend gesperrt, weil eine Rückfrage zur Ausgabe offen ist. Ein vorhandener Restwert kann dabei weiterhin Teil des Datensatzes sein. Wenn die Oberfläche nur eine Null anzeigt, sieht die Sperre wie eine vollständige Einlösung aus. GutscheinWerk nennt im vorhandenen Skrabi-Katalog Kontingente, Laufzeiten, Teilnutzung und protokollierte Sperrungen. Diese Anleitung hilft bei der Vorbereitung einer verständlichen Zustandsanzeige. Sie ist keine rechtliche Bewertung von Gutscheinfristen und behauptet keine echte Ausgabe oder Zahlung.

Wert und Status getrennt notieren

Lege im Bauauftrag einen erfundenen Code mit einem Ausgangswert von vierzig Einheiten an. Nach einer Testeinlösung von zehn bleiben dreißig. Setze anschließend einen getrennten Status „zur Prüfung gesperrt“. Der Restwert bleibt dreißig, die aktuell erlaubte Aktion ändert sich. Diese einfache Übung zeigt, warum ein einzelnes Zahlenfeld den Vorgang nicht erklären kann. Verwende keine existierenden Codes und keine echten Kundendaten in einer öffentlichen Demonstration.

Ergänze die Fragen, die die Oberfläche beantworten soll: Ist der Code bekannt? Welcher Restwert ist dokumentiert? Darf gerade eingelöst werden? Wenn nicht, welcher öffentliche Hinweis hilft weiter? Die interne Begründung kann vertraulich sein; der Kundentext braucht trotzdem einen sachlichen nächsten Schritt.

Entsperren als eigenen Vorgang planen

Verlange eine ausdrückliche Berechtigung zum Sperren und Entsperren. Der Verlauf soll festhalten, wer den Status wann änderte und auf welchen Vorgang sich die Entscheidung bezieht. Ein erfolgloser Einlöseversuch während der Sperre darf den Restwert nicht verändern. Ebenso darf ein wiederholter Klick auf denselben freigegebenen Vorgang nicht zwei Belastungen erzeugen. Die Katalogbeschreibung ist ein Ausgangspunkt, doch solche Übergänge müssen im späteren Backend tatsächlich umgesetzt werden.

Auch Ablaufdatum und Sperre sind getrennte Sachverhalte. Welche Bedingungen für dein konkretes Angebot gelten, muss der Betreiber vor dem Verkauf fachlich prüfen und verständlich formulieren. Ein technisches Statusfeld entscheidet diese Frage nicht. Für die Entwicklung genügen ausdrücklich künstliche Werte und eine lokale Testverwaltung ohne Zahlungsverbindung.

Ein vollständiger Zustandswechsel zur Abnahme

Teste an der fertig gebauten Anwendung nacheinander Ausgabe, Teilnutzung, Sperre, abgewiesenen Versuch und Entsperrung. Der Restwert nach der Entsperrung entspricht dem Stand vor dem abgewiesenen Versuch. Kundenansicht und berechtigtes Partnerdashboard erklären denselben aktuellen Zustand, zeigen aber unterschiedliche interne Details. Ein fremder Partner darf den Code nicht verändern. Mit diesem Ablauf prüfst du Wert, Rechte und verständliche Kommunikation gemeinsam, statt nur einen grünen oder roten Status zu kontrollieren.