# Shopware SAP Business One Schnittstelle

*Shopware → SAP Business One*

**Kurz gesagt:** Eine Shopware-SAP-Business-One-Anbindung hält Shop und ERP auf einer Wahrheit: Jede Shopware-Bestellung wird über die Service Layer zum Kundenauftrag oder zur Ausgangsrechnung in SAP Business One, zugeordnet zum richtigen Geschäftspartner und den richtigen Artikelnummern - während Artikelstammdaten, Preislisten und Lagerbestände zurück in den Shop fließen, damit die Verfügbarkeit aktuell bleibt. Richtig gemacht ist das kein nächtlicher CSV-Import, sondern eine idempotente, delta-fähige Pipeline, die beide Systeme abgleicht, ohne dass jemand Bestellungen oder Bestände abtippt.

## Was eine Shopware-SAP-Business-One-Anbindung wirklich leistet

In Shopware passiert der Verkauf - der Kunde, der Warenkorb, die gewählte Zahlart, die Lieferadresse, die vom Storefront berechnete Steuer. In SAP Business One wird das Geschäft tatsächlich geführt - das Geschäftspartner-Konto, der Artikelstamm, der Lagerbestand, die Preisfindung und jeder Beleg vom Kundenauftrag über die Ausgangsrechnung bis zum Zahlungseingang. Beide Systeme halten sich für den Eigentümer von Kunde und Artikel. Keines liegt falsch, und genau das ist das Problem.

Eine Shopware-SAP-Business-One-Anbindung bringt beide in Übereinstimmung. Bestellungen fließen aus dem Shop als korrekte Belege gegen den richtigen Geschäftspartner und die richtigen Artikel ins ERP; Artikelstamm, Preislisten und Lagerbestände fließen zurück, damit der Shop verkauft, was wirklich vorhanden ist - zum Preis, den die Buchhaltung freigegeben hat. Niemand tippt eine Bestellung in SAP ab, und niemand ändert einen Bestand in Shopware von Hand.

## Welche Daten fließen

| Objekt / Vorgang in Shopware | Wird in SAP Business One zu | Hinweis |
| --- | --- | --- |
| Registrierter / Gastkunde | Geschäftspartner (Kunde, CardCode) | Zuerst gegen bestehenden GP abgeglichen; neue GP mit definiertem CardCode-Kreis und Gruppe |
| Aufgegebene Bestellung | Kundenauftrag (ORDR) | Kopf + Positionen auf Artikelnummern gemappt; Nummernkreis bleibt bei SAP |
| Bezahlte / erfüllte Bestellung | Ausgangsrechnung + Zahlungseingang | Belegstufe gesteuert über Zahlungs- und Fulfillment-Status in Shopware |
| Bestellposition | Belegzeile, je Artikel | Verkaufs- vs. Lagereinheit und Mengeneinheiten-Umrechnung hier gelöst |
| Steuer auf Positionen | Steuerkennzeichen (VAT Group) je Zeile | Inland, EU-OSS und Reverse-Charge auf das richtige SAP-Steuerkennzeichen |
| Artikelstamm (aus SAP) | Produkt in Shopware | ItemCode als Produktnummer; Bezeichnung, Attribute, Aktiv-Kennzeichen |
| Preisliste (aus SAP) | Kundengruppen- / Nettopreise in Shopware | Währung und Preisliste je Geschäftspartner berücksichtigt |
| Lagerbestand (aus SAP) | Verfügbarer Bestand in Shopware | Welche Lager den Shop speisen, verfügbar vs. reserviert, einmal abgestimmt |

Das konkrete Feld-Mapping, die CardCode-Logik, die Steuerkennzeichen und die Frage, welche Lager den Shop speisen, stimmen wir einmalig mit Ihnen und Ihrem SAP-Partner ab und hinterlegen sie in der Pipeline. Danach ordnet das niemand mehr von Hand zu.

## Die Details, an denen einfache Syncs scheitern

Ein nächtlicher CSV-Import oder ein generischer Connector bringt Sie fast ans Ziel und lässt den teuren Teil auf Ihrem Schreibtisch liegen:

- **Geschäftspartner-Zuordnung.** Derselbe Käufer ist heute Gast und morgen registrierter B2B-Debitor. Einen Shopware-Kunden vor dem Anlegen eines neuen GP auf den richtigen bestehenden CardCode aufzulösen - über E-Mail, USt-IdNr. oder externe Nummer - verhindert, dass sich Ihr Debitorenstamm mit Dubletten füllt.
- **Artikel- und Einheiten-Mapping.** Shopware-Produktnummern sind nicht automatisch SAP-Artikelnummern, Varianten vervielfachen das Mapping, und die Verkaufseinheit im Shop kann von der Lagereinheit in SAP abweichen. Die Mengeneinheiten-Umrechnung muss explizit sein, sonst werden Mengen falsch gebucht.
- **Steuerkennzeichen statt Steuersätze.** Shopware berechnet einen Steuerbetrag; SAP braucht ein Steuerkennzeichen (VAT Group). Inland, EU-Fernverkauf im OSS und B2B-Reverse-Charge sind unterschiedliche Kennzeichen, und Netto- gegen Bruttopreisfindung muss passen, sonst stimmt die Ausgangsrechnung nicht mit der Bestellsumme überein.
- **Keine Events aus SAP.** SAP Business One liefert keine Webhooks, also ist der Bestands- und Preis-Sync ein Polling. Bei jedem Lauf alles zu ziehen skaliert nicht; ein Delta-Sync über UpdateDate schon - und er muss die Lebensdauer der Service-Layer-Session respektieren, statt sich bei jedem Aufruf neu anzumelden.
- **Belegnummern und -stufen.** SAP besitzt seine Nummernkreise - die Schnittstelle darf nie eine DocNum erzwingen. Und eine Rechnung für eine Bestellung zu buchen, die Minuten später in Shopware storniert wurde, ist der Weg, wie ein naiver Sync das Konto verfälscht.
- **Teilfehler.** Eine Bestellung kann den Kundenauftrag anlegen, aber an der Rechnung scheitern - oder den GP treffen, aber an einer Zeile hängen bleiben. Die Pipeline braucht Idempotenz - eine stabile Shopware-Bestellreferenz auf dem SAP-Beleg -, damit ein erneuter Versuch fortsetzt statt dupliziert.

## Wie wir sie bauen und betreiben

Wir behandeln das als Pipeline, nicht als Stapellauf von Hand. Shopware-Bestellungen werden über die Admin-API abgeholt oder per Webhook entgegengenommen, validiert, gegen Geschäftspartner und Artikel in SAP aufgelöst und über die Service Layer als abgestimmte Belege in SAP Business One geschrieben. Artikelstamm, Preislisten und Lagerbestände holen wir im Delta-Takt aus SAP und schreiben sie zurück nach Shopware.

Die Pipeline ist idempotent: Jede Shopware-Bestellung trägt eine stabile Kennung, die wir auf dem SAP-Beleg hinterlegen - ein erneuter Lauf, ein Retry oder ein Abbruch der Service-Layer-Session bucht dieselbe Bestellung nie zweimal. Sie läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur - Bestell- und Kundendaten verlassen die EU nicht, was AVV und DSGVO sauber hält.

Und dann halten wir sie am Laufen. Monitoring, Alerting, Incident Response und - entscheidend - das Beobachten von Änderungen an der Shopware-Admin-API und der SAP-Business-One-Service-Layer liegen vertraglich bei uns. Ein fester Ansprechpartner und ein SLA ersetzen das Skript, das niemand betreuen wollte.

## Wann sich diese Anbindung lohnt

Wenn Sie eine Handvoll Bestellungen am Tag abwickeln und jemand sie in zehn Minuten in SAP abtippt, ist ein manueller Ablauf völlig in Ordnung - und wir sagen Ihnen das auch. Die Anbindung lohnt sich, wenn das Bestellvolumen das Abtippen zur eigenen Aufgabe macht, wenn Überverkäufe durch Bestände, die in Shopware dem ERP hinterherhinken, echtes Geld kosten, wenn B2B-Kunden mit bestehenden Debitoren und Preislisten korrekt zugeordnet werden müssen, oder wenn Ihr SAP-Partner Ihnen berechnet, doppelte Geschäftspartner und falsch kontierte Belege zu bereinigen, die eine Pipeline von vornherein verhindert hätte.

## Häufig gestellte Fragen

### Schreiben Sie über die Service Layer oder die DI-API in SAP Business One?

Standardmäßig über die Service Layer (OData v4), weil sie die unterstützte, HANA-taugliche Schnittstelle für SAP Business One 9.x und 10 ist und parallele Last sauber verkraftet. Läuft eine ältere SQL-basierte Installation ohne nutzbare Service Layer oder wird ein bestimmtes Add-on-Objekt gebraucht, weichen wir auf die DI-API aus. Schnittstelle, Firmendatenbank und Lizenzierung stimmen wir vorab mit Ihrem SAP-Partner ab, damit es keine Überraschungen gibt.

### Wie vermeiden Sie doppelte Geschäftspartner für denselben Kunden?

Die Zuordnung ist der schwierige Teil, deshalb machen wir sie explizit. Shopware-Kunden werden über einen von Ihnen festgelegten, eindeutigen Schlüssel gegen bestehende Geschäftspartner in SAP abgeglichen - E-Mail, USt-IdNr. oder eine externe Nummer -, bevor ein neuer GP angelegt wird. Gastbestellungen und B2B-Konten mit bestehendem Debitor behandeln wir über getrennte Regeln. Neue Geschäftspartner erhalten einen definierten CardCode-Nummernkreis und eine feste Gruppe, nie einen zufälligen.

### Wird aus der Shopware-Bestellung ein Kundenauftrag oder eine Ausgangsrechnung?

Das, was zu Ihrem Prozess passt - und oft beides nacheinander. Viele B2C-Shops buchen eine bezahlte Shopware-Bestellung direkt als Ausgangsrechnung plus Zahlungseingang; B2B- und Pick-Pack-Abläufe erzeugen zuerst einen Kundenauftrag und lassen SAP dann Lieferung und Rechnung steuern. Wir bilden Zahlungs- und Fulfillment-Status aus Shopware auf die richtige Belegstufe ab, damit SAP nie vor oder hinter dem tatsächlichen Stand im Shop liegt.

### SAP Business One hat keine Webhooks - wie bleibt der Bestand in Shopware aktuell?

Richtig, SAP Business One sendet keine Events. Deshalb fragen wir die Service Layer in kurzem Takt über UpdateDate-Filter ab, holen nur die Änderungen - Artikelpreise, Lagerbestand, Stammdaten - und schreiben die Deltas zurück nach Shopware. Das Intervall stimmen wir auf Katalogumfang und Bestandsdynamik ab, damit die Verfügbarkeit im Shop dem ERP folgt, ohne die Service-Layer-Session zu überlasten.

### Wer betreibt die Schnittstelle nach dem Go-live?

Wir. Die Pipeline läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur, die wir überwachen. Ändert sich etwas an Shopware oder der SAP-Business-One-Service-Layer, läuft eine Session ab oder scheitert eine Bestellung beim Buchen, ist das unser Alarm - keine böse Überraschung, die Ihr Team entdeckt, wenn ein Kunde nach seiner Bestellung fragt. Sie bekommen einen festen Ansprechpartner, Monitoring und ein SLA statt eines Skripts auf irgendeinem Rechner.

## Verwandte Integrationen

- [Shopify ↔ SAP Business One](https://seamless.engineering/de/integrations/shopify-sap-business-one/): Shopify SAP Business One Schnittstelle
- [Shopware ↔ DATEV](https://seamless.engineering/de/integrations/shopware-datev/): Shopware DATEV Schnittstelle
- [Shopware ↔ sevDesk](https://seamless.engineering/de/integrations/shopware-sevdesk/): Shopware sevDesk Schnittstelle
- [JTL ↔ Amazon](https://seamless.engineering/de/integrations/jtl-amazon/): JTL Amazon Schnittstelle
- [Shopify ↔ weclapp](https://seamless.engineering/de/integrations/shopify-weclapp/): Shopify weclapp Schnittstelle
- [Amazon ↔ NetSuite](https://seamless.engineering/de/integrations/amazon-netsuite/): Amazon NetSuite Schnittstelle

## Nach System

- [Alle Schnittstellen für Shopware](https://seamless.engineering/de/integrations/shopware/)
- [Alle Schnittstellen für SAP](https://seamless.engineering/de/integrations/sap/)

## Scoping-Gespräch anfragen

Sie möchten diese Integration umsetzen und dauerhaft betreiben lassen? Sagen Sie uns, welche Systeme verbunden werden sollen und welche Daten fließen müssen. Festpreis-Angebot zur Aufwandsabschätzung innerhalb von 48 Stunden.

- E-Mail: hello@seamless.engineering
- Kontaktformular: https://seamless.engineering/de/#contact