Redesign bonbon-mueller.de v2 — Part 5: Der AI-Operator — Wie KI unser ERP konfiguriert und die Fulfillment-Automation gebaut hat

Fünf Wochen nach dem Businessplan

In Part 4 war bonbon-mueller.de eine vollständige E-Commerce-Plattform: Kundenkonto, Magazin, Admin-Dashboard, Newsletter. Bestellungen kamen rein. Kunden waren zufrieden.

Aber hinter den Kulissen war Fulfillment noch manuell.

Eine Bestellung eingeht → Shopware öffnen → Kundendaten raus → Lieferschein erstellen → DHL-Label generieren → Tracking in Shopware eintragen → Buchhaltung irgendwo notieren. Für eine Handvoll Bestellungen täglich geht das. Wenn der Shop wächst, kollabiert dieses System.

Die Aufgabe für Woche 5: vollautomatischer Fulfillment-Flow — von der bezahlten Bestellung bis zum DHL-Label, ohne manuelle Zwischenschritte.

Die Entscheidung: ERPNext selbst gehostet

Die naheliegende Lösung wäre ein SaaS-ERP gewesen. Xero, Lexoffice, DATEV — bekannte Namen, monatliche Gebühren, externe Daten.

Wir haben uns dagegen entschieden. Stattdessen: ERPNext, das führende Open-Source-ERP, selbst gehostet im selben Kubernetes-Cluster wie der Shop.

Warum?

Datensouveränität. Kundendaten, Bestellhistorie, Buchhaltung — alles bleibt in der eigenen Infrastruktur. Kein dritter Anbieter hat Zugriff auf Transaktionsdaten.

Kein Vendor Lock-in. ERPNext ist vollständig open source. Keine proprietären Exportformate, kein "Sie brauchen das Upgrade für diese Funktion".

Vollständigkeit. ERPNext deckt nicht nur Buchhaltung ab, sondern auch Lagerverwaltung, Einkauf, CRM, HR — alles in einem System, das mit dem Betrieb wächst.

API-first. ERPNext hat eine vollständige REST API — das ist der entscheidende Punkt für das, was als nächstes kommt.

Der AI-Operator: ERP konfigurieren via API

Traditionelle ERP-Implementierungen sind ein eigenes Genre der Unternehmensgeschichten. Wochen. Externe Berater. Schulungen. Konfigurationssessions. Endlose Klick-Orgien durch verschachtelte Menus.

Wir haben das anders gemacht.

Die KI hat einen API-Key zu ERPNext bekommen. Dann haben wir eine Architektursession gemacht — nicht über Code, sondern über das Geschäft:

*Wie ist die Unternehmensstruktur? Welche Steuerkategorien? Welches Lager? Welche Kundengruppen? Wie soll die Rechnungsnummerierung aussehen?*

Aus diesem Gespräch heraus hat die KI ERPNext direkt via API konfiguriert:

• Unternehmensstruktur — Firmenname, Währung, Steuer-ID, Buchungskreis
• Kontenrahmen — angepasst auf deutsche Anforderungen (SKR03)
• Steuerkategorien — AM-DE-Inland (7% Lebensmittel Inland), AM-CH-Export (0% steuerfreie Ausfuhrlieferung §4 Nr. 1a UStG)
• Lager — Grafenwald Lager als Standardlager für alle Bestellungen
• Kundengruppen — Webshop für B2C, B2B für Geschäftskunden
• Naming Series — AM-SO-.YYYY.-.##### für Sales Orders (strukturiert, jahresbezogen)
• Item Codes — Produktnummern aus Shopware als ERPNext-Artikel angelegt

Die KI hatte dabei Zugriff auf drei Informationsquellen gleichzeitig: die ERPNext API für Lesen und Schreiben, die Strapi-Logs (pseudonymisiert) für Kontext über laufende Bestellungen, und den Strapi-Code als Integrationsschicht, um zu verstehen, wie die Systeme miteinander reden sollen.

Das Ergebnis: Eine vollständig konfigurierte ERPNext-Instanz in einem Bruchteil der Zeit, die ein klassisches ERP-Projekt benötigt hätte — ohne einen einzigen externen Berater.

Strapi als Integrations-Bus

Der elegante Teil der Architektur ist, wie die drei Systeme miteinander kommunizieren.

Strapi steht in der Mitte — nicht als CMS, sondern als Integrations-Bus. Es kennt die Geschäftslogik. Es weiß, wie Shopware mit ERPNext spricht. Es verarbeitet Webhooks, transformiert Datenformate, orchestriert den Flow.

Die Integration läuft in zwei Richtungen:

Shopware → ERPNext: Order Sync

Wenn eine Bestellung in Shopware bezahlt wird, feuert das Shopware Event Bridge Plugin einen Webhook an Strapi. Strapi übernimmt:

1. Shopware-Bestellung vollständig abrufen (Kunde, Positionen, Lieferadresse)

2. Kunden in ERPNext finden oder neu anlegen

3. Bestellpositionen mappen (Produktnummern, Mengen, Einzelpreise, Lager)

4. Steuerlogik ermitteln — Deutschland: 7% Lebensmittel, Ausland: 0% Export

5. Sales Order in ERPNext erstellen und einbuchen (docstatus: 1)

6. Sync-Event in Strapi-Datenbank für Nachvollziehbarkeit loggen

Deduplication ist eingebaut: Wenn ein Sales Order mit dieser Shopware-Bestellnummer bereits existiert, wird er übersprungen. Keine Duplikate.

ERPNext → DHL → Shopware: Fulfillment Automation

Der zweite Flow schließt den Kreis. Wenn das Lager eine Bestellung kommissioniert und in ERPNext einen Lieferschein (*Delivery Note*) erstellt, feuert ERPNext einen Webhook zurück an Strapi. Strapi übernimmt:

1. DHL-Label erstellen — Lieferadresse aus Shopware holen, via DHL Parcel DE API ein Versandlabel anfordern

2. Label-PDF anhängen — das PDF wird base64-kodiert direkt an den ERPNext-Lieferschein angehängt

3. Shopware aktualisieren — Tracking-Nummer setzen, Lieferstatus auf "verschickt", Bestellstatus auf "abgeschlossen"

Das Ergebnis: Der Lager-Mitarbeiter klickt in ERPNext auf "Lieferschein einbuchen". Danach ist das DHL-Label fertig, die Bestellung in Shopware als verschickt markiert, und der Kunde bekommt seine Tracking-Nummer — alles automatisch.

Was das in der Praxis bedeutet

Bevor diese Integration existierte:

1. Bestellung in Shopware prüfen

2. Kundendaten manuell in DHL-Portal eingeben

3. Label generieren, ausdrucken

4. Tracking-Nummer manuell in Shopware eintragen

5. Buchhaltungsnotiz irgendwo festhalten

Jetzt:

1. In ERPNext: Lieferschein einbuchen.

Das ist der Unterschied zwischen einem Betrieb, der mit dem Volumen wächst, und einem, der daran erstickt.

Der breitere Punkt

Was hier passiert ist, geht über eine technische Integration hinaus.

Ein ERP-System traditionell einzuführen bedeutet: externen Berater engagieren, Anforderungen dokumentieren, Konfiguration manuell durchklicken, Schulungen abhalten, Anpassungen beauftragen. Zeitrahmen: Wochen bis Monate. Kosten: entsprechend.

Unser Ansatz war ein anderer: KI als Operator. Nicht als Code-Generator, sondern als System-Konfigurator. Die KI bekommt API-Zugang, ein Geschäftskontext-Gespräch, und konfiguriert das ERP direkt über die Schnittstelle — strukturiert, nachvollziehbar, anpassbar.

Das setzt voraus, dass das System eine gute API hat (ERPNext hat das), dass jemand mit Überblick die Geschäftslogik erklären kann (der Orchestrator), und dass die KI den Kontext aus mehreren Quellen gleichzeitig verarbeiten kann — Code, Logs, API-Dokumentation.

Genau das ist Agentic Development in seiner deutlichsten Form: nicht Mensch-ersetzt-durch-KI, sondern Mensch-plus-KI-als-System-das-schneller-und-breiter-operiert-als-einer-allein.

Wie es weitergeht

• Produktbewertungen — Social Proof direkt auf den Produktseiten
• Geschenkversand mit Grußkarte — eine Funktion, die bei Bonbons naheliegt
• Google Shopping — Merchant Feed live schalten für bezahlte Reichweite
• Erste organische Rankings — die Content-Cluster-Strategie zeigt erste Ergebnisse