SYLIUS NEXT.JS PWA SUBIEKT GT 3D-LOGISTIK D2C

Plantoris

Das Schwierigste an diesem Shop war nicht der Warenkorb, sondern der Karton.

Ogrody Drama verkaufen seit drei Generationen Pflanzen: Anbau seit 1974, Gartencenter und Planungsbüro bei Zbrosławice seit 1996, heute 50 Mitarbeitende. Plantoris ist ihr Eintritt in den landesweiten polnischen Markt. Wir haben das gesamte System von Grund auf gebaut: Sylius als Engine, Next.js als Frontend-Schicht, Subiekt GT als Single Source of Truth für die Ware und einen eigenen 3D-Packalgorithmus, ohne den dieser Shop nicht eine einzige Lieferung korrekt berechnen würde.

Plantoris — der Onlineshop von Ogrody Drama, gebaut auf Sylius und Next.js — Plantoris — ein landesweiter Pflanzenshop in Polen, von Grund auf gebaut auf Sylius und Next.js.

01 Herausforderung und Ansatz

× Vorher

Lebende Ware sprengt das Standardmodell eines Shops. Eine Pflanze verändert im Lauf der Saison ihre Maße, manche Positionen dürfen nicht gestapelt werden, andere dürfen bei Frost nicht versendet werden. Fertige E-Commerce-Engines haben dafür kein Feld in der Datenbank.
Die Versandkosten ergeben sich nicht aus dem Gewicht. Ein zwei Meter hohes Bäumchen und ein Substratsack mit derselben Masse sind zwei völlig verschiedene Sendungen. Eine Preisliste mit Pauschalen bedeutet entweder, bei Bestellungen draufzuzahlen, oder den Kunden abzuschrecken.
Zwei Lager, eine Bestellung. Pflanzen und Zubehör verlassen unterschiedliche Standorte, der Kunde sieht aber einen Warenkorb und einen Betrag.
Die Wahrheit über die Ware liegt im ERP. Bestände, Preise und Mehrwertsteuer leben in Subiekt GT, und niemand wird im Shop eine zweite, parallele Datenbank pflegen.
Zielgröße, nicht Startgröße. Die Architektur musste vom ersten Tag an einen Katalog in der Größenordnung von 100.000 Positionen und mehrere zehntausend Bilder verkraften.

→ Unser Ansatz

Backend first. Wir haben mit der Integration und der Logik begonnen, nicht mit dem Aussehen. Die grafische Ebene entstand parallel bei der Agentur des Kunden und kam erst dann in die Arbeit, als die Engine bereits rechnete.
Logistikdaten als Bürger erster Klasse. Gewicht, drei Maße, das Flag „kann anderes darauf gestellt werden“, Verpackungstyp, Wachstumsphase und Verfügbarkeitsmonat sind Produktfelder und kein Satz in der Beschreibung.
Regeln statt Ausnahmen. Saisonalität, Versand-Cut-off und der Versandstopp bei Frost sind eine Konfiguration im Panel und kein Anruf beim Entwickler im November.
Sylius, kein fertiger Shop von der Stange. Bei dieser Zahl an Sonderregeln ist ein Framework mit offenem Domänenmodell auf ein Jahr gerechnet günstiger als der Kampf mit den Grenzen einer geschlossenen Plattform.

02 Technologie-Stack

Womit wir das gebaut haben.

Sylius (Symfony)

E-Commerce-Engine, Produktmodell mit gärtnerischen Attributen, Steuerzonen, Währungen, Administrationspanel mit ausgebautem ACL

Next.js (PWA)

Präsentationsschicht, umgesetzt auf Basis der von der Agentur des Kunden gelieferten Designs

Subiekt GT

bidirektionale Integration: Produkte, Preise, Bestände und Mehrwertsteuer in den Shop, Bestellungen und Geschäftspartner zurück ins ERP

Cloudflare CDN + Images

Distribution und automatische Konvertierung der Bilder nach WebP und AVIF

Apaczka

Versandetiketten und Sendungsstatus, die in das Kundenpanel übernommen werden

Sentry

Fehler-Monitoring auf Backend- und Frontend-Seite

Marketing Automation

Kaufereignisse, abgebrochene Warenkörbe, Kundensegmente, Integration von Bewertungen

XML-Feeds

Google Merchant, Ceneo, Werkzeuge zur Überwachung der Wettbewerbspreise

03 Lösungen

Drei Dinge, die kein fertiger Shop leistet.

3D-Packalgorithmus (Bin Packing)

Das System schätzt die Versandkosten nicht, es berechnet sie. Vor dem Abschluss der Bestellung simuliert es die physische Anordnung der Ware: Es nimmt die Maße und das Gewicht jeder Position, prüft das Stapelbarkeits-Flag (empfindliche Pflanzen haben es nicht), wählt die günstigste Kombination von Verpackungen aus dem verfügbaren Pool an Kartons, Kisten und Paletten und berechnet erst daraus den Listenbetrag für den Kunden. Die Verpackungen haben eigene Maße, eigene Logistikkosten und einen eigenen Lagerbestand.

Warum das wichtig ist: Bei einem Sortiment vom Samentütchen bis zum zwei Meter hohen Bäumchen ist der Unterschied zwischen Berechnung und Pauschale eine reale Marge bei jeder Bestellung.

Split Shipment

Der Warenkorb teilt sich automatisch in Teilbestellungen nach dem Standort der Ware auf, Pflanzen getrennt, Töpfe und Zubehör getrennt, mit korrekt summierten Versandkosten. Der Kunde sieht eine Bestellung, die Lager sehen ihre eigenen Listen, und das ERP erhält den vollständigen Datensatz.

Saison, Wetter und Cut-off

Der Versand lebender Ware ist keine stetige Funktion. Wir haben einen konfigurierbaren Stichtag und eine Uhrzeitgrenze für den Versand umgesetzt, die saisonale Sichtbarkeit von Kategorien und Produkten, pro Monat definierte Logistikregeln sowie einen Versandstopp bei Temperaturen um den Gefrierpunkt, den der Operator aus dem Panel auslöst. Dazu Verkaufspuffer pro Produkt und einen eigenen Status „Packbeginn“, der ausschließlich für die Packerei sichtbar ist.

Architekturdiagramm von Plantoris: Subiekt GT, Sylius, Next.js, Apaczka, Cloudflare und Sentry — Subiekt GT bleibt die Single Source of Truth für die Ware und tauscht Daten mit Sylius in beide Richtungen aus. Sylius hält die Logik, die kein fertiger Shop hat, und daraus ergibt sich das Versandetikett.

Wie der 3D-Packalgorithmus die Versandkosten berechnet, statt sie zu schätzen — Ein Substratsack und ein zwei Meter hohes Bäumchen wiegen gleich viel. Eine Pauschale nach Gewicht würde beide identisch bepreisen; der Algorithmus wählt die Verpackungen und berechnet den Betrag erst daraus.

Plantoris-Katalog mit Produktfiltern und botanischen Parametern — Katalog mit vollständigen Produktfiltern. Die gärtnerischen Attribute sind Produktfelder und lassen sich daher genauso filtern wie der Preis.

04 Umfang der Umsetzung

Der übrige Umfang der Umsetzung.

Katalog: Produkt in mehreren Kategorien gleichzeitig, Varianten mit eigenem Preis und eigener EAN, Cross-Selling, gärtnerische Attribute (Frosthärte, Standort, Boden), visuelles Mega-Menü mit Kacheln
Vorbestellung: Vorbestellung mit eigenem Liefertermin, Zahlung im Voraus, Sperre für das Zusammenlegen verfügbarer und nicht verfügbarer Ware
Digitale Pflanzenpässe: Der QR-Code am Produkt führt zu einer virtuellen Pflanzenkarte mit Pflegeanleitung und fügt die Pflanze dem Bereich „Mój Ogród“ (Mein Garten) hinzu, ohne sie im Shop suchen zu müssen
Plant Doctor: virtueller Gärtner, ein KI-Agent, der Fragen zur Auswahl und Pflege beantwortet
Treueprogramm: Integration mit dem bestehenden Punktesystem des Kunden: ein Login, Punktestand und Punktehistorie, Schwellen, Fortschrittsbalken, Prämien, Gutschein-Wallet, Angebote für die jeweilige Stufe
Aktionen: zeitlich begrenzte Aktionen prozentual und als Betrag, einmalig und mehrfach einlösbare Gutscheine, ein Tab mit Angeboten, Pflanze der Woche und des Monats, vollständige Unterstützung der Omnibus-Richtlinie mit der Historie des niedrigsten Preises der letzten 30 Tage
Panel und CMS: Rollen und Berechtigungen (Administrator, Packerei, Kundenservice), Banner, Ratgeber-Blog, Materialien zum Download, Informationsseiten und Kontaktformular
Planungsservice: Online-Bestellung einer Gartenplanung, Fragebogen und Kostenschätzung, Dokumentation mit einer Pflanzenliste, die zurück in den Warenkorb führt

05 Wie wir dieses Projekt geführt haben

Sechs Monate im Modell Backend first, mit harten Ergebnissen am Ende jeder Phase.

PHASE 1

Fundamente

Technische Workshops, Mapping der Daten aus dem ERP, Dev- und Stage-Umgebungen, CDN.

PHASE 2

ERP-Integration

Synchronisation von Produkten, Preisen und Beständen, gärtnerische Attribute in der Datenbank, XML-Feeds.

PHASE 3

Logistik

Split Shipment, Packalgorithmus, Marketing Automation, Sendungsstatus.

PHASE 4

UX- und KI-Logik

Nutzerpfade, Abstimmung der Mockups mit der Agentur des Kunden, Umsetzung des virtuellen Gärtners.

PHASE 5

Frontend

Design-Review der gelieferten Entwürfe, Umsetzung der Views in Next.js, Konfiguration des CMS.

PHASE 6

Stabilisierung

Lasttests, Abnahmetests, Schulung des Teams, Migration auf die Produktivumgebung.

06 Ergebnisse

Was sich verändert hat.

Ein Unternehmen mit lokaler Reichweite verkauft in ganz Polen, mit demselben Sortiment und demselben Wissen.

Die Versandkosten sind kein Raten mehr. Für jede Bestellung sind die Verpackungen berechnet und nicht eine Pauschale nach Gewicht.

Das ERP ist die alleinige Single Source of Truth für die Ware geblieben. Das Team arbeitet in Subiekt wie bisher, der Shop zieht von selbst nach.

Die Saison steuert das Panel, nicht der Entwickler. Cut-off, Sichtbarkeit der Kategorien und der Versandstopp bei Frost liegen in den Händen des Kundenteams.

Das Planungsbüro hat einen Vertriebskanal gewonnen, denn die Gartenplanung endet mit einer Pflanzenliste, die sich im selben Shop kaufen lässt.

Eine Architektur, die auf einen Katalog in der Größenordnung von 100.000 Positionen vorbereitet ist, sodass der Ausbau des Sortiments kein Neuschreiben des Systems bedeutet.

Keine Prozentzahlen. Der Shop läuft erst seit Kurzem, und statt eindrucksvoller Zahlen ohne Deckung zeigen wir, was dieses System tatsächlich verändert hat.

07 Ähnliche Referenzen

Haben Sie ein ähnliches Problem?

Wenn Ihr Warenkorb Maße, Saison und zwei Lager zugleich verstehen muss, trägt ein fertiger Shop das nicht. Wir zeigen Ihnen, wie man das korrekt berechnet.