Wie bringt man Shopware 6 das Rechnen in Quadratmetern, Kubikmetern und Stunden bei?

Für die Werkstätten einer Kunsthochschule wurde aromicon mit einer maßgeschneiderten Digitalisierungslösung, das heißt einer Online-Materialbibliothek mit Bestellfunktion beauftragt. Als Basis bot sich der Einsatz eines Open Source Shopsystems an. Zahlreiche Anpassungen wie zentraler Uni-Login, Bestellfreigaben über lokale Terminals, Bestellmengen, Preis- und Bestandsverwaltung, Lagerhaltung für Meterware, Flächen und Volumen sowie die Berücksichtigung interner Zahlungen über Budgets mussten bewältigt werden. Hier wird gezeigt, wie die Umsetzung mit Shopware 6 realisiert wurde.

Unsere Aufgabe

Die Aufgabe bestand darin, das große Angebot an Materialien und Halbzeugen für jede Werkstatt, sei es die Metallwerkstatt, die Holzwerkstatt, die Digitalwerkstatt oder andere, für die Studierenden durchsuchbar zu machen. Die Studierenden sollten so in die Lage versetzt werden, sich vor dem Besuch der jeweiligen Werkstatt einen Überblick über die zur Verfügung stehenden Materialien, deren Eigenschaften und Abmessungen, die sichere Handhabung und den umfangreichen Maschinenpark wie zum Beispiel diverse 3D-Drucker, CNC-Maschinen oder die Laserschneidanlage zu verschaffen.

Ziel der Hochschule war es, in erster Linie die Lehre zu verbessern. Eine Art Materialbibliothek sollte dabei den Studierenden die Planung ihrer Projekte im Vorfeld erleichtern. Das Werkstattpersonal sollte von Routineaufgaben entlastet werden und somit mehr Zeit für die Beratung der Studierenden zur Verfügung haben.

Gleichzeitig sollte es eine Bestell- und Online-Zahlungsfunktion geben und so der dahinterliegende Verwaltungsaufwand auf ein Minimum reduziert und Barzahlungen abgelöst werden.

Konzept für einen Onlineshop mit Zuschnitt für mehrere Dimensionen

Schnell war klar, dass ein individuell angepasster Onlineshop die beste Basis für die Lösung dieser Anforderung ist. Hier bot sich Shopware 6 als Open Source E-Commerce-System mit umfangreichen Funktionen und hoher Flexibilität für die komplexen Anforderungen der Kunsthochschule an.

Aber der Teufel steckt bekanntlich im Detail. Wie sich herausstellte, war dies auch hier der Fall.

So war uns bis zu diesem Zeitpunkt nicht bewusst, dass Shopware 6 standardmäßig keine Materialbestellungen kleiner "1" unterstützt.
Das bedeutete, dass zum Beispiel eine Gewindestange mit einer Länge von 2 Metern bestellt werden konnte, aber nicht mit einer Länge von 0,5 Metern.
Ein weiterer Aspekt, der berücksichtigt werden musste, war die Möglichkeit, Preise, Bestände und Mengen für zwei Dimensionen, das heißt Flächen, abzubilden. Dies ist beispielsweise bei Materialien wie MDF-Platten oder Plexiglas der Fall. Bei Blöcken, wie zum Beispiel Modellbauschaum, kam dann die dritte Dimension, also Volumina, ins Spiel.

Ein weiteres Anliegen war es, die zentralen Anmeldedaten der Studierenden für die Computerpools auf dem Campus auch für den Werkstattshop zu nutzen. Dabei stand die Benutzerfreundlichkeit im Vordergrund, das heißt die Studierenden sollten ihre Werkstattaufträge nahtlos und komfortabel über ihre bereits vorhandenen Zugangsdaten abwickeln können. Gleichzeitig musste eine einfache Authentifizierung gewährleistet sein.

Gibt es eine Lösung oder sind die Grenzen von Shopware 6 erreicht?

Wie kann man nun das Problem der Bestellmengen kleiner “1” und der Lagerhaltung und Preisberechnung für Flächen und Volumen lösen oder sind hier schon die Grenzen von Shopware erreicht?

So sind wir vorgegangen:

1. Der schnelle Weg: Gibt es bereits ein Shopware Plugin?
   Als erstes wurden natürlich nach geeigneten Shopware 6 Plugins gesucht. Aber zu diesem Zeitpunkt ohne jeden Erfolg. Es gab nicht einmal ein Plugin, was so ungefähr passen könnte und das man hätte erweitern können.

2. Ansatz des Programmierers: Datentyp in MySQL ändern
   Der zweite Versuch war der klassische Ansatz eines Informatikers: Macht die Variable nicht, was sie soll, wird ihr Datentyp einfach angepasst.
   Leider ist das aufgrund der Type Castings und Definition auf Integer nicht möglich.

3. Mit Köpfchen: Man rechnet die ISO-Maßeinheit einfach um
   Aus dem Physikunterricht kennt man ja noch die Umrechnung von Maßeinheiten. So sind 0,5 Meter eben auch 500 Millimeter. Und schon hat man eine elegante Lösung. Man rechnet einfach alles auf die Basiseinheiten, Millimeter, Quadratmillimeter und Kubikmillimeter sowie Sekunden um. An jedem Produkt kann definiert werden, welche Verkaufseinheit gelten soll und welche die “Basis”-Einheit ist. Somit werden aus 0.5 m2 , entweder 5000 cm2 oder 500.000 mm2.

Einstellungen der Preisberechnung: Verkaufseinheiten, Maßeinheiten, minimaler und maximaler Zuschnitt der Platte, Schrittgröße des Zuschnitts

Der Rattenschwanz – Änderung an Preisberechnung, Bestandspflege und Warenkorb

Damit war nun ein valider Lösungsansatz gefunden, es ergaben sich dadurch aber gleichzeitig weitere Baustellen:
Als nächstes mussten die Preisberechnung und die Bestandsverwaltung angepasst werden. Stellt man das System auf kleine Basiseinheiten wie Millimeter um, kann eine Preis- und Bestandspflege im Administrationsbereich leicht zu einer sportlichen Rechenaufgabe werden.
Zum Beispiel werden MDF-Platten mit Standardmaßen von 125 cm x 83 cm geliefert und der Preis in Euro/qm vom Lieferanten angegeben. Was kostet denn da eine Platte oder eben nur X x Y Millimeter?
Bei der Preisberechnung musste man weiterhin einen variablen Verschnittfaktor berücksichtigen, da dieser erheblichen Einfluss auf den Verkaufspreis haben kann.

Ein weiteres Problem kam hinzu. Legt man nicht mehr 1 Kubikmeter in den Warenkorb, sondern nun umgerechnet in Kubikmillimeter den Wert von 1.000.000.000, stößt man an die Grenze des Datentyp INT von MySQL. Hier bot es sich an, den Datentyp der Felder “stock” und “available_stock” auf BIG INT zu ändern. Dies ließ sich einfach über ein Migrationsskript realisieren. Somit wurden die Type Casts und Type Declarations nicht verletzt.

Danach mussten nur noch alle Stellen angepasst werden, an denen der Bestand angezeigt wird, und dieser entsprechend in die Verkaufseinheit umgerechnet und um die Verkaufseinheit erweitert werden. Durch die gute Erweiterbarkeit von Shopware 6, war dies problemlos umsetzbar. Im Frontend wurden die Anzeige in der Kategorie, die Produktdetailseite, Warenkorb, Checkout und Anzeige in der Bestellung angepasst. Der Administrationsbereich wurde in der Produktübersicht, in den Produktdetails, Varianten und Bestelldaten erweitert.

Produktdetailseite mit Varianten (unterschiedliche Plattengrößen und Stärken)

Ergebnis: Administrationseingabe Bestand in Quadratmeter und Frontend Bestellung Quadratmillimeter

Modifizierte Bestandsverwaltung im Shopware 6 Administrationsbereich

Warenkorb mit Zuschnitt, Projektdetails und gesperrten Checkout (bestellt werden kann nur über Terminal-PCs), Checkout nur über lokalen Terminal-PC mit Studenten-Account möglich

Preispflege inkl. Zuschlag für den Verschnitt

Und sonst noch: Zentrales Login lösen, Paymentmethode und Checkout anpassen

Für das Login der Studierenden wird der Radius-Server der Hochschule angefragt und die Accounts verifiziert. Zusätzlich kann das Werkstattteam im Administrationsbereich Gastnutzer anlegen. Der Checkout ist nur von bestimmten Terminal-Rechnern in der Werkstatt möglich und zu jeder Bestellung müssen Projektangaben gemacht werden.
Ist bei bestimmten Materialien oder Maschinen eine Beratung nötig, müssen Warenkörbe vor dem Checkout durch einen Mitarbeiter freigegeben werden. Dies geschieht auch über die Authentifizierung des Radius-Servers.
Als Payment-Methode wurde PayPal verwendet und das System um eine weitere Zahlungsmethode für interne Budgets erweitert. Diese Methode muss ebenfalls von einem Mitarbeiter im Checkout manuell freigegeben werden.

Authentifizierung über den Radius-Server

Für die Nutzung des hochschulinternen Radius-Servers zur Anmeldung im Werkstatt-Shop wurde ein eigenes Plugin entwickelt. Als Radius Client wurde die Bibliothek von Drew Phillips (https://github.com/dapphp/radius) genutzt. Die Serververbindung konnte vollständig über die Plugin-Konfiguration im Administrationsbereich angepasst werden. Um einen separaten Login zu vermeiden, wurde der Standard-Login im Frontend angepasst, um auch Benutzernamen anstelle von E-Mails zuzulassen. Alle Links zur Registrierung wurden entfernt, da eine Registrierung über das Storefront nicht möglich sein sollte. Zur Anpassung des Login-Prozesses wurde die Klasse "Shopware\Core\Checkout\Customer\SalesChannel\LoginRoute" verwendet, da keine geeigneten Events vorhanden waren.

In der Funktion "login" wurde überprüft, ob im E-Mail-Feld keine E-Mail enthalten ist. In diesem Fall wurden die Daten auf dem Radius-Server überprüft. Wenn der Nutzer erfolgreich vom Radius-Server authentifiziert wurde, wurde der Kunde anhand des Benutzernamens, der in den CustomFields des Kunden gespeichert wurde, aus der Shop-Datenbank geladen. Falls der Kunde noch nicht in der Datenbank vorhanden war, wurde ein Fehler zurückgegeben, der auf eine modifizierte Registrierungsseite im Storefront führte. Hierfür wurden die Controller "\Shopware\Storefront\Controller\RegisterController" und "\Shopware\Storefront\Controller\AuthController" überschrieben.

Auf der Registrierungsseite musste der Student lediglich seinen Namen vervollständigen und die E-Mail-Adresse anpassen (standardmäßig wurde die Studenten-E-Mail-Adresse verwendet). Anschließend erfolgte die automatische Registrierung. Nach Abschluss des Vorgangs konnte sich der Student entweder mit seinem Studenten-Account oder ganz normal mit seiner E-Mail-Adresse einloggen.

Aktuelle Herausforderungen im Betrieb

Der Shop erfreute sich von Anfang an großer Beliebtheit. Die Nutzung trug dazu bei, die Aufenthaltszeiten in den Werkstätten während den Corona-Beschränkungen zu minimieren und die geltenden Regeln in Bezug auf die maximale Anzahl gleichzeitiger Nutzer einzuhalten.

Es war klar, dass es sich bei dem Shop um ein Nonprofit-Projekt handelt. Allerdings stellen die PayPal-Gebühren eine Herausforderung dar. In einigen Fällen übersteigen die Gebühren den Wert der Bestellung, beispielsweise bei einer Bestellung von nur zwei Schrauben. Um die Hürde für die Nutzung des Shops niedrig zu halten, wurde bewusst auf einen Mindestbestellwert verzichtet.

Wie so oft ergab sich auch hier das Problem des Micropayments, insbesondere da eine Hochschule bei der Auswahl des Zahlungsdienstleisters eingeschränkt ist. Für die Zukunft steht hier noch eine Lösung aus.

Das Projekt hat nicht nur die Herausforderungen der Corona-Zeit gemeistert, sondern die praktische Wissensvermittlung in den Werkstätten digitalisiert. Deshalb wird das Angebot weiter ausgebaut und weitere Werkstätten der Hochschule in den Shop integriert und mit Terminal-PCs ausgestattet.

Zu den Autoren:

Alf Jahn ist Geschäftsführer der Digitalagentur aromicon mit Sitz in Halle (Saale). Seit 2008 entwickelt aromicon als Digitalisierungspartner E-Commerce-Lösungen, Apps und KI-Anwendungen für seine Kunden in der DACH-Region. Alf verantwortet neben der Geschäftsführung den Vertrieb sowie die strategische und konzeptionelle Beratung der Kunden.

Stefan Richter verantwortet die konzeptionelle und technische Umsetzung der Projekte sowie den Bereich der Eigenentwicklung zukünftiger digitaler Produkte bei aromicon.