PlentyONE kann viel. Wir entwickeln, was eurem Prozess noch fehlt.
Wir erweitern PlentyONE mit Plugins, Schnittstellen und externen Web-Anwendungen - von individueller Shoplogik bis zum automatisierten Datenaustausch mit Lager, Fulfillment, Lieferanten und internen Systemen.
- PlentyONE und PlentyONE Shop
- Plugin, Schnittstelle oder externe Anwendung
- REST-API, Webhooks oder Dateiaustausch
- Standard nutzen, individuell ergänzen
Standardsoftware endet dort, wo der eigene Prozess beginnt.
PlentyONE deckt viele typische Abläufe im E-Commerce ab. Unternehmensspezifische Sortimente, individuelle Paketlogiken, besondere Freigaben oder gewachsene Verbindungen zu anderen Systemen lassen sich jedoch nicht immer mit einer Einstellung oder einem Marketplace-Plugin abbilden.
Dann entstehen manuelle Zwischenschritte: Daten werden exportiert, in Excel verändert und wieder importiert. Mitarbeitende übertragen Informationen zwischen Systemen oder gleichen Bestände und Statuswerte von Hand ab. Im Shop werden Kompromisse eingegangen, weil die vorhandene Funktion nicht zum tatsächlichen Verkaufsprozess passt.
Wir prüfen, an welcher Stelle die fehlende Logik sinnvoll ergänzt werden sollte. Manche Anforderungen gehören direkt in ein PlentyONE-Plugin. Andere sind als externe Anwendung stabiler, weil sie unabhängig vom Shop oder vom Systemkern weiterentwickelt werden können.
- Ein Marketplace-Plugin deckt nur einen Teil des benötigten Ablaufs ab.
- Daten werden regelmässig aus PlentyONE exportiert, bearbeitet und wieder importiert.
- Shop, Lager, Lieferant oder Fulfillment tauschen Informationen nur über Dateien und E-Mails aus.
- Eine individuelle Sortiments-, Paket- oder Preislogik lässt sich im Standard nicht abbilden.
- Mehrere Plugins lösen Teilprobleme, funktionieren gemeinsam aber nicht zuverlässig.
- Mitarbeitende übernehmen manuell die Verbindung zwischen Systemen.
Nicht jede fehlende Funktion braucht dieselbe Lösung.
Eine Erweiterung muss dort gebaut werden, wo sie technisch und fachlich hingehört. Eine Funktion im Shop stellt andere Anforderungen als ein interner Prozess oder ein dauerhafter Datenaustausch mit einem Drittsystem.
Deshalb entscheiden wir nicht vorab, dass jede Anforderung ein PlentyONE-Plugin werden muss. Wir prüfen zuerst den Ablauf, die vorhandenen Schnittstellen und die Abhängigkeiten zu anderen Komponenten.
Das Ziel ist keine möglichst umfangreiche Individualisierung. Das Ziel ist eine Lösung, die den fehlenden Prozess abbildet und auch nach dem nächsten Systemupdate noch nachvollziehbar bleibt.
Plugin oder externe Anwendung?
Beides ist möglich, und beides ist an anderer Stelle richtig. Diese Punkte entscheiden:
- Plugin, wenn die Funktion unmittelbar im PlentyONE-System gebraucht wird.
- Plugin, wenn sich vorhandene Plugin-Schnittstellen verwenden lassen.
- Plugin, wenn die Erweiterung eng mit Shop oder Backend verbunden ist.
- Plugin, wenn Nutzer die Funktion in ihrer gewohnten Umgebung bedienen sollen.
- Externe Anwendung, wenn mehrere Systeme gemeinsam gesteuert werden.
- Externe Anwendung, wenn eine eigene Benutzeroberfläche gebraucht wird.
- Externe Anwendung, wenn umfangreichere Prozesslogik unabhängig vom Shop laufen soll.
- Externe Anwendung, wenn Daten ausserhalb von PlentyONE verarbeitet oder ergänzt werden.
- Externe Anwendung, wenn die Lösung später auch mit einem anderen System funktionieren soll.
Beides lässt sich kombinieren: Ein schlankes Plugin stellt Daten und Funktionen im System bereit, die umfangreichere Logik übernimmt die externe Anwendung.
Unser Vorgehen in drei Schritten
Prozess und Systemgrenzen verstehen
Wir klären, welche Funktion fehlt, welche Daten benötigt werden und welche Systeme beteiligt sind. Entscheidend ist nicht nur der gewünschte Normalfall, sondern auch, wie Fehler, Änderungen und Sonderfälle behandelt werden sollen.
Den richtigen Erweiterungspunkt wählen
Wir prüfen, ob die Anforderung durch Konfiguration, ein vorhandenes Plugin, eine individuelle PlentyONE-Erweiterung, eine Schnittstelle oder eine externe Anwendung am sinnvollsten gelöst wird.
Entwickeln, testen und dokumentieren
Die Umsetzung wird in einer geeigneten Testumgebung beziehungsweise einem getrennten Plugin-Set geprüft. Abhängigkeiten, Datenflüsse und relevante Einstellungen werden dokumentiert, bevor die Lösung produktiv eingesetzt wird.
Schnittstellen, die nicht nur Daten verschieben
Eine funktionierende Integration besteht nicht allein aus einem API-Aufruf. Es muss festgelegt werden, welches System für welche Information führend ist und was bei fehlenden, doppelten oder widersprüchlichen Daten passiert. Wir berücksichtigen deshalb unter anderem:
- eindeutige Zuordnung von Artikeln, Varianten, Aufträgen und Kontakten
- Übertragung nur tatsächlich veränderter Daten
- Prüfung von Pflichtfeldern und Formaten
- nachvollziehbare Fehlerprotokolle
- Wiederholung fehlgeschlagener Übertragungen
- Schutz vor doppelter Verarbeitung
- kontrollierte Behandlung von Statusänderungen
- Begrenzung und Berechtigung von API-Zugriffen
Dadurch entsteht kein Datenaustausch, der nur im Idealfall funktioniert, sondern ein kontrollierbarer Prozess.
Was wir für PlentyONE entwickeln
Individuelle PlentyONE-Plugins
Plugins für Funktionen, die unmittelbar innerhalb von PlentyONE oder einer bestehenden Shopumgebung benötigt werden - eigene Logiken, Backend-Funktionen, Datenverarbeitung oder Erweiterungen, die sich in bestehende Plugin-Sets einfügen müssen.
Shop- und Sortimentslogik
Konfiguratoren, Produktabhängigkeiten, kompatible Sets und individuelle Auswahlprozesse, gezielt in den Shop integriert. Dabei berücksichtigen wir, wie Artikel, Varianten, Merkmale und Warenkorbdaten in PlentyONE strukturiert sind.
Schnittstellen zu externen Systemen
Wir verbinden PlentyONE mit Anwendungen, die Daten bereitstellen oder weiterverarbeiten: Lager, Versand, Fulfillment, Lieferanten, Buchhaltung oder interne Unternehmenssysteme. Welche Technik zum Einsatz kommt, hängt von den verfügbaren Schnittstellen des jeweiligen Systems ab.
Externe Web-Anwendungen
Wenn eine Funktion nicht sinnvoll in den Shop oder das ERP gehört, entwickeln wir eine separate Web-Anwendung. Sie greift über definierte Schnittstellen auf die benötigten PlentyONE-Daten zu und bleibt technisch vom Systemkern getrennt.
Automatisierte Datenflüsse
Aufträge, Bestände, Artikeldaten, Statuswerte oder Dokumente werden zwischen PlentyONE und anderen Anwendungen automatisch übertragen, geprüft und verarbeitet.
Bestehende Erweiterungen
Wir analysieren vorhandene Plugins, individuelle Themes und externe Integrationen. Abhängig von Quellcode, Lizenz und technischer Grundlage können bestehende Lösungen korrigiert, erweitert oder kontrolliert ersetzt werden.
PlentyONE Shop und plentyShop LTS sind nicht dasselbe.
Viele bestehende Shops arbeiten weiterhin mit plentyShop LTS beziehungsweise der früheren Bezeichnung Ceres. Der aktuelle PlentyONE Shop besitzt eine andere technische Grundlage und andere Möglichkeiten zur Erweiterung. Eine Anpassung lässt sich deshalb nicht automatisch von einer Shopgeneration auf die andere übertragen.
Vor Projektbeginn prüfen wir, welche Shopgeneration im Einsatz ist, welche Plugins und Abhängigkeiten bereits vorhanden sind, an welcher Stelle die neue Funktion eingreifen muss, ob eine Anpassung im Shop oder ausserhalb davon sinnvoller ist und welche Auswirkungen eine spätere Migration hätte. So entsteht keine neue Abhängigkeit, die beim nächsten grösseren Wechsel wieder zum Problem wird.
Updates lassen sich nicht versprechen. Risiken lassen sich reduzieren.
Keine individuelle Erweiterung ist automatisch für jede zukünftige Systemversion geeignet. Die Abhängigkeit von Updates lässt sich jedoch deutlich reduzieren: Wir verwenden nach Möglichkeit dokumentierte Schnittstellen und vorgesehene Erweiterungspunkte, trennen individuelle Logik klar vom Systemkern und halten Abhängigkeiten nachvollziehbar fest.
Vor relevanten Updates kann die Erweiterung in einem separaten Plugin-Set oder einer Testumgebung geprüft werden. So werden mögliche Konflikte sichtbar, bevor sie den produktiven Betrieb betreffen.
Beispiele aus der Praxis
Alu-Profile-LED
System-Konfigurator für LED-Profile als Plentymarkets-Plugin - direkt im Ceres-Theme verankert.
Paketverknüpfung
Die Logik, die Plentymarkets standardmässig nicht abbildet - als eigene Web-App neben dem ERP.
Internes Werkzeug - Asset-Workflow
Interne Anwendung für ein Hamburger Mittelstandsunternehmen - Mandanten-Vertraulichkeit, deshalb ohne Domain.
Was Entscheider zuerst fragen.
Kann ein bestehendes PlentyONE-System individuell erweitert werden?
In vielen Fällen ja. Zunächst muss geprüft werden, welche System- und Shopversion verwendet wird, welche Plugins bereits installiert sind und welche offiziellen Erweiterungspunkte verfügbar sind.
Wann ist ein Plugin besser als eine externe Anwendung?
Ein Plugin eignet sich für Funktionen, die eng mit PlentyONE oder dem Shop verbunden sind. Eine externe Anwendung ist häufig sinnvoller, wenn umfangreiche Prozesslogik, mehrere Systeme oder eine eigene Oberfläche beteiligt sind.
Arbeitet ihr auch mit bestehenden plentyShop-LTS- beziehungsweise Ceres-Shops?
Bestehende LTS-Umgebungen können weiterhin analysiert und erweitert werden. Dabei sollte jedoch berücksichtigt werden, dass PlentyONE inzwischen einen neuen Shop als Nachfolger anbietet. Neue Anpassungen müssen deshalb auch im Hinblick auf eine mögliche spätere Migration bewertet werden.
Könnt ihr vorhandene Marketplace-Plugins anpassen?
Das hängt davon ab, ob der Quellcode verfügbar ist und welche Lizenz- und Entwicklungsbedingungen gelten. Häufig ist es sinnvoller, das vorhandene Plugin über vorgesehene Schnittstellen zu ergänzen, statt seinen Kern zu verändern.
Welche externen Systeme können angebunden werden?
Grundsätzlich kommen Systeme infrage, die eine dokumentierte Schnittstelle oder einen verlässlichen Dateiimport und -export bereitstellen. Vor einer Zusage prüfen wir verfügbare Daten, Authentifizierung, technische Grenzen und erwartetes Datenvolumen.
Bleibt die Erweiterung nach Updates funktionsfähig?
Eine uneingeschränkte Garantie für zukünftige Versionen wäre unseriös. Durch offizielle Schnittstellen, getrennte Logik, dokumentierte Abhängigkeiten und Tests vor Updates lässt sich das Risiko jedoch erheblich reduzieren.
Wie lange dauert eine PlentyONE-Erweiterung?
Das hängt von der Anzahl der beteiligten Systeme, der Datenqualität und den benötigten Sonderfällen ab. Nach einer technischen Vorprüfung erhaltet ihr einen nachvollziehbaren Umfang und einen realistischen Zeitrahmen.
Könnt ihr auch nur beraten, ohne direkt zu entwickeln?
Ja. Wenn zunächst geklärt werden muss, ob eine Anforderung mit dem Standard, einem Marketplace-Plugin oder einer individuellen Entwicklung gelöst werden sollte, kann die technische Analyse als eigener Schritt erfolgen.
Welche Funktion fehlt zwischen PlentyONE und eurem Ablauf?
Zeigt uns die manuelle Zwischenlösung, das unpassende Plugin oder das System, mit dem PlentyONE noch nicht zuverlässig kommuniziert. Wir prüfen, wo die Erweiterung technisch sinnvoll angesetzt werden sollte.
PlentyONE-Projekt prüfen lassen