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.

Shopware SAP Business One Schnittstelle

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.