Zum Inhalt springen

This page is available in English. Switch to English

Magento-Shop zu langsam? Hyvä macht ihn schnell. Mehr zur Hyvä-Entwicklung

Abstrakte Skulptur: eine dünne, flache Platte, deren Oberfläche ein fein eingeschnittenes Muster paralleler Linien trägt.

Projekt · VAMED Vitality World

Gutscheine, die der Gast selbst ausdruckt

Online gekauft, zu Hause ausgedruckt, an der Kassa eingelöst. Dafür brauchte es einen eigenen Produkttyp in Magento, ein PDF mit Barcode und eine Kassa, die den Code kennt.

Ein Gutschein ist ein seltsames Produkt

Er wird gekauft wie eine Ware, aber nicht versendet. Er ist nicht verbraucht, wenn er beim Käufer ankommt, sondern erst, wenn ihn jemand an der Kassa vorlegt, und das ist oft nicht derselbe Mensch. Zwischen Kauf und Einlösung liegt womöglich ein Jahr.

Für VAMED Vitality World sollten Gäste einen Gutschein online kaufen, ihn sofort selbst ausdrucken oder weitergeben, und er sollte im Haus an der Kassa funktionieren.

Was dafür gebaut wurde

Ein eigener Produkttyp

Der Gutschein ist in Magento ein Produkt wie jedes andere: mit Preis, Warenkorb und Bestellung. Nur entsteht am Ende kein Versand, sondern ein Dokument.

PDF mit Barcode

Nach dem Kauf entsteht ein druckfertiges PDF mit einem Barcode. Der Barcode macht den Gutschein eindeutig, nicht das Papier, auf dem er liegt.

Anbindung an die Kassa

Die Kassa im Haus muss den Code kennen und einlösen können. Erst damit wird aus einem hübschen PDF ein Zahlungsmittel und nicht nur ein Ausdruck.

Selbst drucken oder verschenken

Der Käufer druckt den Gutschein sofort aus oder gibt ihn weiter. Kein Warten auf die Post, und der Beschenkte muss nicht der Käufer sein.

Es gab nichts, was man abschauen konnte

Gutscheine zum Selbstausdrucken waren damals kein Muster, das man kannte. Es gab kein Modul, das man kaufen konnte, und keinen Shop, bei dem man nachsehen konnte, wie er es macht. Das war Magento 1, und es war die Zeit vor REST: Eine Schnittstelle war nichts, was man aufruft, sondern etwas, das man baut.

Die Idee, auf der alles steht, ist eine Entscheidung darüber, wo der Wert liegt. Nicht im Dokument, sondern im Code. Das PDF ist nur der Träger. Sobald das feststeht, lösen sich die Fragen, die vorher unlösbar aussahen: Der Gast darf ausdrucken, so oft er will. Er darf den Gutschein weitergeben. Er darf ihn per Mail weiterschicken. Nichts davon vervielfacht den Wert, weil nicht das Blatt zählt, sondern was die Kassa dazu weiß.

Danach war die Arbeit die, die man vorher zu Ende denken muss. Ein Gutschein liegt vielleicht ein Jahr in einer Schublade. Was ihn erzeugt hat, muss ihn ein Jahr später noch erkennen. Er darf sich genau einmal einlösen lassen, und die Entscheidung darüber fällt an einer Kassa im Haus, nicht im Shop. Das ist die Art Anforderung, die ein System entweder von Anfang an mitdenkt oder später schmerzhaft nachrüstet.

Was davon belegbar ist

Das System war mehr als fünf Jahre im Einsatz. Wann genau es gebaut wurde, ist in meinen Unterlagen nicht festgehalten, und wie VAMED es heute löst, weiß ich nicht. Zahlen zu verkauften Gutscheinen habe ich keine.

Warum das Projekt hier steht: Es war ein Shop, aber ein ungewöhnlicher. Verkauft wurde etwas, das nie versendet wird, und das ändert fast alles dahinter: den Produkttyp, das, was nach der Bestellung entsteht, und die Frage, wo und wann eingelöst wird. Ein Shop ist nicht dasselbe wie ein Paketversand, und diese Art Arbeit mache ich bis heute.

Haben Sie ein Produkt, das kein Paket ist?

Gutscheine, Zugänge, Termine, Lizenzen: Alles, was verkauft und nicht versendet wird, braucht eigene Logik. Schildern Sie mir, was bei Ihnen verkauft wird und was danach passieren soll.