Ein leistungsfähiger Onlineshop allein reicht für eine durchgängige Auftragsabwicklung nicht aus. Sobald Bestellvolumen, Sortiment oder Vertriebskanäle wachsen, müssen Shop, Warenwirtschaft, Einkauf, Lager, Versand und Buchhaltung zuverlässig zusammenspielen. Die Verbindung von Shopware und weclapp kann dafür eine geeignete Grundlage schaffen.
Entscheidend ist jedoch nicht nur, dass beide Systeme Daten austauschen. Unternehmen benötigen klare Zuständigkeiten, konsistente Stammdaten und kontrollierbare Prozesse. Eine Integration sollte deshalb als Geschäftsprozessprojekt geplant werden – nicht als rein technische Installation eines Connectors.
Shopware und weclapp: Rollen im Gesamtsystem

Shopware bildet als Commerce-Plattform insbesondere den digitalen Verkauf ab. Dazu gehören Produktdarstellung, Kategorien, Preise, Kundenkonten, Warenkorb, Checkout, Aktionen und die Übergabe an Zahlungs- und Versandprozesse. Für neue Projekte ist Shopware 6 die relevante Produktgeneration. Die im früheren Beitrag behandelte Version Shopware 5 ist technisch überholt und sollte bei einer Modernisierung nicht mehr als Zielplattform dienen.
weclapp ist eine cloudbasierte ERP-Lösung für betriebswirtschaftliche Abläufe. Abhängig von Konfiguration und gebuchtem Funktionsumfang lassen sich dort unter anderem Artikel, Kunden, Angebote, Aufträge, Bestände, Einkauf, Lagerprozesse, Rechnungen und weitere kaufmännische Vorgänge verwalten. Die genaue Eignung muss anhand der individuellen Prozesse, Mandantenstruktur und Integrationsanforderungen geprüft werden.
Für die Systemarchitektur ist eine klare Aufgabenteilung sinnvoll: Shopware verantwortet das Einkaufserlebnis und die Commerce-Logik, während weclapp als führendes System für ausgewählte kaufmännische und logistische Daten dienen kann. Welche Anwendung bei Artikeln, Preisen, Beständen, Kunden oder Belegen die Datenhoheit besitzt, muss vor der Umsetzung verbindlich festgelegt werden.
Welche Daten und Prozesse synchronisiert werden sollten
Eine typische Integration überträgt Bestellungen aus Shopware an weclapp. Dort können daraus Aufträge, Lieferprozesse und Rechnungen entstehen. In der Gegenrichtung werden beispielsweise verfügbare Bestände oder Bearbeitungsstatus an den Shop zurückgegeben. Je nach Geschäftsmodell kommen Produktdaten, kundenspezifische Preise, Versandinformationen, Stornierungen oder Gutschriften hinzu.
Nicht jeder Datensatz muss in beide Richtungen synchronisiert werden. Eine unkontrollierte bidirektionale Übertragung erhöht die Komplexität und kann widersprüchliche Änderungen erzeugen. Besser ist eine fachlich definierte Synchronisationsmatrix, die für jedes Datenobjekt Quelle, Ziel, Übertragungsrichtung, Auslöser und Fehlerbehandlung festlegt.
- Artikel: Artikelnummern, Varianten, Einheiten, Steuermerkmale und gegebenenfalls beschreibende Produktdaten.
- Preise: Standardpreise, Kundengruppenpreise, Aktionspreise und steuerliche Behandlung.
- Bestände: verfügbare Mengen, Reservierungen, Lagerorte und Regeln für Sicherheitsbestände.
- Kunden: Rechnungs- und Lieferadressen, Kontaktdaten sowie Zuordnung zu Geschäfts- oder Privatkunden.
- Belege: Bestellungen, Aufträge, Lieferungen, Rechnungen, Stornierungen und Gutschriften.
- Statusdaten: Zahlungsstatus, Versandstatus, Trackinginformationen und Bearbeitungsfehler.
Besondere Aufmerksamkeit benötigen Teillieferungen, Retouren, Gutscheine, Rabatte, Versandkosten, Rundungsdifferenzen und nachträgliche Änderungen. Diese Fälle wirken im Shop einfach, können im ERP jedoch mehrere Belege oder Buchungslogiken auslösen. Sie sollten deshalb bereits im Fachkonzept beschrieben und mit realistischen Testfällen geprüft werden.
Technische Integration: Connector, API oder Middleware
Die Anbindung kann über einen verfügbaren Connector, eine individuelle API-Integration oder eine Integrationsplattform erfolgen. Welche Variante geeignet ist, hängt von Prozessumfang, Anpassungsgrad, Betriebsmodell und internen Kompetenzen ab. Vor einer Entscheidung ist zu prüfen, welche Shopware- und weclapp-Versionen tatsächlich unterstützt werden und wie Erweiterungen in beiden Systemen berücksichtigt werden.
Ein Standard-Connector kann für überschaubare Abläufe einen schnellen Einstieg ermöglichen. Er sollte jedoch nicht allein nach seiner Funktionsliste bewertet werden. Relevant sind auch Protokollierung, Wiederholungsmechanismen, Überwachung, Zuordnungstabellen, Updatefähigkeit und der Umgang mit API-Limits oder vorübergehend nicht erreichbaren Diensten. Bei komplexen Prozesslandschaften kann eine Middleware Vorteile bieten, weil sie Transformationen, Routing und Monitoring zentralisiert.
Cloud- und SaaS-Architekturen entlasten Unternehmen vom Betrieb bestimmter Infrastrukturkomponenten, beseitigen aber nicht die Integrationsverantwortung. APIs und Datenmodelle entwickeln sich weiter, Zugriffsrechte ändern sich und Erweiterungen können neue Felder oder Statuswerte einführen. Die Schnittstelle benötigt daher einen geregelten Lebenszyklus mit Tests, Versionskontrolle, Betriebsdokumentation und klaren Zuständigkeiten.
- Welche Anwendung ist je Datenobjekt das führende System?
- Werden Daten ereignisbasiert oder in geplanten Intervallen übertragen?
- Wie werden Dubletten, Zeitüberschreitungen und unvollständige Datensätze behandelt?
- Wie erkennen Verantwortliche fehlgeschlagene Übertragungen?
- Wie lassen sich Vorgänge sicher erneut verarbeiten, ohne Doppelbelege zu erzeugen?
- Wie werden Änderungen an Plugins, Apps, APIs und Datenfeldern getestet?
