---
title: "Integrationen (ERP, PIM, WMS, Zahlungen)"
description: "Verbinden Sie Ihren Shop mit den Systemen, die das Geschäft wirklich betreiben. Idempotent, beobachtbar und robust, auch wenn die API des Drittanbieters gerade ausfällt."
language: "de"
canonical: "https://zapolu.com/de/services/integrations/"
---

# Integrationen (ERP, PIM, WMS, Zahlungen)

Der Shop ist nur eines von mehreren Systemen. Das Geschäft läuft
daneben auf einem ERP für Bestand und Buchhaltung, einem PIM für
Produktdaten, einem WMS für das Fulfillment, Zahlungsdienstleistern
und einem CRM für das Marketing. Die meisten Produktionsstörungen
beginnen nicht im Shop selbst, sondern in der Integrationsschicht
dazwischen.

## Systeme, an die wir anbinden

- **ERP:** SAP Business One, Microsoft Dynamics 365 Business Central,
  Pohoda, Money S5, Odoo, NetSuite
- **PIM:** Akeneo, Pimcore, Plytix und die internen Excel-Tabellen,
  die sich für ein PIM ausgeben
- **WMS / 3PL / Fulfillment:** Zásilkovna, Packeta, GLS, DPD, FedEx,
  hauseigene Lagersysteme
- **Payments:** Stripe, GoPay, ComGate, PayU, Adyen, Mollie, dazu
  Fraud-Detection und Recurring Billing
- **CRM / Marketing:** HubSpot, Klaviyo, Mailchimp, Salesforce
- **Analytics / Daten:** BigQuery, Snowflake, Segment, GA4

## Wie wir sie bauen

- **Idempotent.** Jeder Webhook darf zweimal ausgelöst werden, ohne
  einen inkonsistenten Zustand zu erzeugen, denn im
  Produktionsbetrieb treten Retries auf.
- **Beobachtbar:** Jeder Aufruf zwischen zwei Systemen wird mit
  Correlation-ID geloggt. Wenn eine Bestellung nicht im WMS ankommt,
  zeigt das Log in einer Minute, wo sie steckt.
- **Resilient.** Fällt der Drittanbieter aus, überlebt die Integration
  das: Dead-Letter-Queues, Exponential Backoff und Werkzeuge für
  manuelles Replay.
- **Versionierte Verträge.** Der API-Vertrag liegt im Repo, eine
  schemabrechende Änderung des Anbieters fällt schon beim Deployment
  auf, nicht erst in der Produktion.
- **Getestet**, mit Contract-Tests gegen aufgezeichnete Responses und
  Smoke-Tests gegen die Sandbox bei jedem Deployment.

## Woher diese Regeln kommen

Nichts davon ist Theorie. Jede dieser Regeln hat in einem Shop, an
dem wir gearbeitet haben, einmal Lehrgeld gekostet:

- Ein Status-Sync stand wochenlang still, ohne je zu scheitern: Das
  ERP schickte immer wieder 300.000 Status für Bestellungen, die es
  im Shop nie gab. Das erschöpfte das Fehlerbudget des Import-Tools
  und brach jeden Lauf still ab, bevor die eigentlichen Daten
  verarbeitet wurden. Seitdem gilt: Fehlerbudgets werden überwacht,
  nicht nur konfiguriert.
- Ein frisch deployter Bestell-Sync überschrieb Felder, die dem
  Marktplatz-Connector gehörten, und die Sendungen eines ganzen Tages
  erreichten die Marktplätze nie. Seither hat jede synchronisierte
  Spalte genau einen deklarierten Eigentümer, und der Sync rührt
  fremde Zeilen nicht an.
- Eine Stored Procedure im ERP warf SQL-Exceptions und meldete
  trotzdem „Erfolg“. Aufgefallen ist das, weil wir vor dem Go-live
  1.300 echte Bestellungen gegen die Integration abgespielt haben;
  das ist inzwischen die Standardprobe für bestellkritische Flows.
- Ein fehlerhafter Feed hätte beinahe Zehntausende Produkte in einem
  einzigen Lauf gelöscht. Lösch-Schwellenwerte mit Circuit Breaker
  gehören seitdem zu jedem Katalog-Sync, den wir bauen.
- Zahlungen fanden ihre Bestellungen nicht mehr, weil die Firewall
  des Hosters die Webhooks des Zahlungsdienstleisters drosselte. Der
  Fix war eine Whitelist; ihn zu finden hieß, HTTP-Logs zu lesen, die
  sich vorher niemand angesehen hatte.

## B2B-Commerce

B2B ist ein anderes Geschäft als DTC: Käufer sind Angestellte von
Firmen, Preise hängen von Verträgen ab, und Bestellungen laufen durch
Genehmigungsprozesse. Auch diese Schicht bauen wir. Dazu gehören
Firmenkonten mit Rollen und Hierarchien, kundenspezifische Kataloge
und Vertragspreise, Quote-to-Order-Workflows, Zahlungsbedingungen
(Net 30/60/90, Kreditlimits, Rechnungsanbindung an das ERP) sowie
Procurement-Integration über Punchout (OCI, cXML, Ariba) und EDI für
Kunden, die weiterhin klassische EDI-Bestellungen (850) senden.

## Wie ein Projekt üblicherweise beginnt

Der Umfang von Integrationsarbeit ergibt sich aus dem Fehler, der
schon sichtbar ist: die Bestellung, die nie im WMS ankam, die
Bestandszahl, die jede Nacht ein Stück driftet, das CSV, das jemand
jeden Morgen von Hand neu eintippt. Wir gehen diesen Ablauf von Ende
zu Ende durch, halten Umfang und Festpreis schriftlich fest und
bauen den Ersatz so, dass der nächste Fehler sofort im Monitoring
auftaucht, statt tagelang unbemerkt zu bleiben. Der laufende Betrieb,
Monitoring inklusive, kann als monatlicher Retainer bei uns bleiben.