Jeder Weg, wie ein Auftrag eintreffen kann

Marktplätze, APIs, E-Mail-Bestellungen, gehostete Portale, EDI, Punchout — OrderHUBx erfasst sie alle in einer orchestrierten Warteschlange.

Das Eingangsproblem, das die meisten Hersteller nicht zugeben

Gehen Sie in das Backoffice eines typischen mittelständischen Herstellers und zählen Sie die Wege, auf denen ein Auftrag tatsächlich eintrifft. Da ist der Amazon-Storefront, den das Marketing-Team vor zwei Jahren gestartet hat. Da ist die WooCommerce-Seite, die der Gründer immer noch „die Website" nennt. Da ist eine Innendienstmitarbeiterin, die PDF-Bestellungen aus ihrem Posteingang ins ERP eintippt. Da sind zwei Distributoren, die auf EDI 850 bestehen. Und da ist dieser eine Großkunde mit Coupa, der ständig fragt, wann der Punchout-Katalog endlich live geht.

Die meisten Hersteller bekommen Aufträge über vier bis sieben verschiedene Methoden herein. Das Ganze wird mit Handarbeit, Copy-Paste und dem institutionellen Gedächtnis der einen Person zusammengehalten, die weiß, wie jede Integration kaputtgeht. Wenn diese Person in den Urlaub fährt, staut sich die Warteschlange.

Diese Seite behandelt jede Methode des Auftragseingangs auf der OrderHUBx-Plattform — die Marktplatz-APIs, die B2B-Direktwege und die Distributor-Netzwerk-Kanäle — und wie jede einzelne unter der Haube aussieht. Gleiche Engine, unterschiedliche Eingangstüren. Eine Warteschlange am Ende.

D2C-Marktplatz-Integrationen

Direct-to-Consumer-Marktplatz- und Storefront-Konnektoren. Jede Bestellung, jede Rückerstattung, jeder Bestandsticker wird zurück zur Plattform synchronisiert — und nach der Auftragsabwicklung zurück zum ursprünglichen Kanal.

Amazon (SP-API)

FBA und FBM, Multi-Marketplace-Abdeckung, vollständige Lebenszyklus-Synchronisation.

  • Amazon Selling Partner API (SP-API) — LWA OAuth, rollenbasierter Zugriff
  • FBA-Bestandsabrufe und FBM-Auftragsimport im 30-Minuten-Takt
  • DE-, AT-, CH-, FR-, IT-, ES-, NL- und UK-Marktplätze aus einem einzigen europäischen Verkäuferkonto
  • Synchronisation von Bestellungen, Beständen, Rückerstattungen, Retouren und Gebühren-Events
  • Markenregistrierte Funktionen: A+ Content-Abgleich, Behandlung markengeschützter ASINs
  • SKU-zu-ASIN-Mapping mit Override pro Marktplatz

Otto Market (Partner Connect)

Artikel, Bestellungen, Bestand, Auftragsabwicklung — die volle Partner-Connect-API-Oberfläche für den zweitgrößten Marktplatz Deutschlands.

  • Otto Market Partner-API mit OAuth 2.0-Authentifizierung
  • Artikel-Feed-Veröffentlichung, Variantenverwaltung, Preis- und Bestandsaktualisierungen
  • Bestellbestätigung innerhalb des SLA von Otto, mit Verlust-Prevention bei Überverkauf
  • Versandbestätigung mit Carrier (Hermes, DHL) und Tracking-Sync-Back
  • Erfassung von Retouren, Erstattungen und Reklamationen über die Retouren-API
  • Markenregistrierungs- und Brand-Asset-Feeds für autorisierte Hersteller

Kaufland Marketplace (Seller API)

Aufträge, Bestände, Versand auf einem der am schnellsten wachsenden Marktplätze in DACH — mit Abdeckung in DE, AT, CZ, SK, PL.

  • Kaufland Seller API (REST + HMAC) für Bestellungen und Bestand
  • Multi-Storefront-Abdeckung: kaufland.de, kaufland.at, kaufland.cz, kaufland.sk
  • Bestellimport mit automatischer Steuerlogik pro Lieferland (USt 19%/20%/21%/23%)
  • Versandbestätigung mit Tracking-Rückmeldung an Kaufland Global Marketplace
  • Retouren-Erfassung mit Gutschrift-Workflow
  • Performance-Metriken-Abruf (Lieferzeit, Stornoquote, Bewertung)

Zalando Partner Program Demnächst

Connected-Retail- und ZFS-Integration (Zalando Fulfillment Solutions) für Fashion-, Beauty- und Sport-Hersteller.

  • Zalando Partner-API (zMS / Connected Retail)
  • Store-to-Zalando-Bestandsabgleich für Retail-integrierte Partner
  • ZFS-Workflow (Zalando Fulfillment Solutions) für Ship-from-Zalando-Sendungen
  • Return-Management mit den 100-Tage-Rückgabefristen von Zalando
  • Brand Portal-Anbindung für Content- und Asset-Synchronisation
  • Umsatzreporting und Partner-Rechnungen via API

WooCommerce (REST API v3)

Native WordPress-/WooCommerce-Erfassung. Multi-Store aus einem Tenant.

  • WooCommerce REST API v3 mit Consumer-Key/Secret-Authentifizierung
  • Vollständiger Auftragslebenszyklus: erstellt, in Bearbeitung, abgeschlossen, storniert, erstattet
  • Multi-Store-Unterstützung — viele WooCommerce-Sites in einem OrderHUBx-Tenant
  • Import von Kundendatensätzen mit E-Mail-basierter Deduplizierung
  • Push-Back von Produktkatalog und Bestandsmengen
  • Custom-Field-Mapping für Theme- und Plugin-spezifische Daten

eBay (Trading API)

Listings, Bestellungen, Bewertungen — Multi-Account, wenn Sie mehrere Stores betreiben.

  • eBay Trading API mit Token-basierter Authentifizierung
  • Auftragsimport über alle Listings und Multi-Account-Konfigurationen hinweg
  • Bestandssynchronisation mit Mengen- und Preisaktualisierungen
  • Versandbestätigung und Push-Back von Tracking-Nummern
  • Käufer-Messaging-Hooks und Bewertungsverwaltung
  • Listing-Status-Abgleich (aktiv, beendet, verkauft)

Shopify Demnächst

REST Admin API- und Storefront-API-Konnektor derzeit in der Implementierung.

  • Shopify Admin REST API für Bestellungen, Produkte, Kunden, Bestand
  • Storefront-API-Unterstützung für Headless- und Custom-Checkout-Flows
  • Webhook-Abonnements für orders/create, orders/updated, refunds/create
  • Multi-Location-Bestandssynchronisation mit Zuweisungsregeln
  • Shopify Plus B2B-Kataloge werden in der Account-Pricing-Logik berücksichtigt
  • Option zur Registrierung als Fulfillment-Service für FBM-artiges Routing

Custom Storefronts

Wenn es JSON POSTen kann, kann es in OrderHUBx landen. Headless, maßgeschneidert, alles möglich.

  • Dokumentierte REST-Endpunkte für Bestellungen, Kunden, Bestand
  • Webhook-Abonnements für Status-Events zurück zum Storefront
  • OAuth 2.0 Client-Credentials-Flow für Server-zu-Server-Integration
  • HMAC-Signatur-Verifizierung bei eingehenden Webhooks
  • JSON-Schema-Validierung mit Reject-and-Retry-Semantik
  • Im Produktivbetrieb mit maßgeschneiderten Headless-React-Storefronts und Legacy-ASP.NET-Sites gleichermaßen im Einsatz

B2B-Direkteingangsmethoden

Für Unternehmen, die direkt bei Ihnen kaufen — nicht für Wiederverkäufer. Programmatische APIs, geparste E-Mail-Bestellungen, gehostete Portale, EDI und vollständige Punchout-Integration mit den E-Procurement-Plattformen, die Enterprise-Einkäufer tatsächlich nutzen.

REST API

Vollständiger programmatischer Auftragslebenszyklus für Käufer, die ihre eigenen Systeme integrieren.

  • Endpunkte für Anlegen, Ändern, Stornieren, Status und Dokumentenabruf
  • OAuth 2.0 Client-Credentials- und Authorization-Code-Flows
  • Rate-Limit von 1.000 Anfragen pro Minute pro Tenant mit Burst-Toleranz
  • Webhook-Callbacks für Status-Events: bestätigt, allokiert, versandt, zugestellt, Ausnahme
  • Idempotenz-Schlüssel auf allen Schreiboperationen, um doppelte Bestellungen zu verhindern
  • Versionierte Endpunkte mit 12-monatigen Deprecation-Fenstern

E-Mail-PO-Erfassung

Speziell entwickelter Parser für die PDF- und Text-Bestellungen, die nach wie vor in Posteingängen eintreffen.

  • Überwachter Posteingang pro Tenant (POP3/IMAP oder Weiterleitungs-Alias)
  • Trainiert auf gängige PO-Formate: SAP, NetSuite, Acumatica, Epicor Prophet 21, Custom-Word-Vorlagen
  • Positionsextraktion mit SKU-Auflösung gegen Ihren Katalog
  • Konfidenzbewertung pro Feld; Parses mit niedriger Konfidenz werden in eine manuelle Prüfwarteschlange geleitet
  • Korrekturen der Prüfer fließen zurück, um künftige Parses für diesen Käufer zu verbessern
  • Original-PDF wird zur Auditierung am Auftragsdatensatz aufbewahrt

Gehostetes B2B-Portal

Das gebrandete Bestellportal, in das sich Ihre B2B-Direktkunden tatsächlich einloggen.

  • Account-basierte Preisgestaltung — vertraglich vereinbarte Preise pro Kunde, niemals Listenpreis
  • Rollenbasierter Zugriff: Buyer-Admin, Requisitionierer, AP-/Buchhaltungs-Viewer
  • Nachbestelllisten und gespeicherte Auftragsvorlagen pro Account
  • Quote-to-Order-Workflow mit Genehmigungs-Routing auf Ihrer Seite
  • Bestellhistorie, herunterladbare Rechnungen, monatliche Kontoauszüge
  • Durchsetzung von Net-30-/Net-45-/Net-60-Zahlungszielen am Checkout

EDI

Das vollständige Transaktions-Set, das große B2B-Käufer und Einzelhändler erwarten.

  • EDI 850 — Bestellung eingehend
  • EDI 855 — Bestellbestätigung ausgehend, innerhalb des Käufer-SLA
  • EDI 856 — Advance Ship Notice ausgehend, mit Detailtiefe auf Karton- oder Palettenebene
  • EDI 810 — Rechnung ausgehend, positionsgenau zur 850 abgeglichen
  • EDI 820 — Zahlungsavis eingehend, gegen offene Rechnungen verbucht
  • Direkte VAN-Anbindung (TrueCommerce, SPS Commerce, OpenText, IBM Sterling) oder AS2 mit Zertifikatsverwaltung

Punchout (cXML und OCI)

Für Käufer auf Coupa, Ariba, SAP Concur, Jaggaer, Oracle iProcurement.

  • cXML PunchOutSetupRequest-Authentifizierung mit Shared-Secret-Credentials
  • Gehostete Katalog-Session, gebunden an den Benutzer des Käufers, mit dessen vertraglichen Preisen
  • cXML PunchOutOrderMessage gibt Warenkorbpositionen an das Beschaffungssystem zurück
  • cXML OrderRequest oder EDI 850 eingehend, sobald der Genehmigungs-Workflow des Käufers abgeschlossen ist
  • cXML ConfirmationRequest, ShipNoticeRequest, InvoiceDetailRequest, PaymentRemittanceRequest — vollständiges Dokumenten-Set
  • OCI (Open Catalog Interface) form-encoded Variante für Legacy-SAP-SRM-Umgebungen

CSV-/Excel-Batch-Upload

Übergangsweise Erfassung für Accounts, die noch nicht auf Portal, API oder EDI sind.

  • Drag-and-Drop-CSV- oder XLSX-Upload über das Portal
  • Spalten-Mapping-Vorlagen pro Account gespeichert
  • Validierung vor dem Import: SKU-Auflösung, Preisstufen-Checks, Lieferadress-Verifizierung
  • Fehlerhafte Zeilen werden mit zeilenweiser Korrekturoberfläche in Quarantäne verschoben
  • Erfolgreiche Uploads landen als native Aufträge in derselben Warteschlange
  • Nützlich als Zwischenschritt, während EDI oder Punchout implementiert werden

Für einen tiefen Einblick, was Punchout eigentlich ist und wie der cXML-Flow unter der Haube funktioniert, siehe Punchout-Kataloge und B2B-Beschaffungsintegration.

Distributor-Netzwerk-Eingangsmethoden

Für Hersteller, die über Distributoren verkaufen, die wiederum weiterverkaufen — Tier-A-Master-Distributoren, regionale Partner, Value-Added-Reseller. Klar abgegrenzt vom B2B-Direkteingang, weil die Workflows vertraglich gebundene Partner voraussetzen, nicht transaktionale Käufer.

Geschütztes Distributor-Portal

Nur autorisierte Partner — mit den Vertragsbedingungen direkt eingebaut.

  • Login pro Distributor mit Credential-basiertem Zugriff (keine öffentliche Anmeldung)
  • Distributor-spezifische Preisverträge auf jeder Position durchgesetzt
  • Echtzeit-ATP (Available-to-Promise) je Lager und ETA
  • Empfehlungen für Substitut-SKUs, wenn der angeforderte Artikel knapp ist
  • Rahmen-PO-Abrufe sichtbar, mit verbleibenden Commitment-Mengen
  • Distributor-spezifische Katalogansichten (nur die Produkte, zu deren Weiterverkauf sie autorisiert sind)

EDI 850 (Distributor)

Für Tier-A-Master-Distributoren, die auf EDI-Infrastruktur arbeiten.

  • Eingehende 850, gebunden an den Trading-Partner-Identifier des Distributors
  • Distributor-spezifische 855-Bestätigung innerhalb des verhandelten SLA
  • 856 ASN mit Pack-Hierarchie-Detail (Karton, Palette, Sendung)
  • 810-Rechnung übermittelt zu Distributor-Vertragspreisen
  • VAN-Routing-Tabellen pro Distributor gepflegt
  • Funktionale Bestätigungen (997) zur Compliance-Verfolgung

Rahmen-PO-Abruf-Workflow

Distributoren rufen Mengen gegen einen Rahmen-PO mit Jahres-Commitment ab.

  • Rahmen-PO angelegt mit SKUs, Vertragsbedingungen, jährlichen Commitment-Mengen
  • Distributor ruft Mengen gegen den Rahmen nach Bedarf ab
  • Laufender Verbrauch pro SKU und pro Abruf nachverfolgt
  • Alerts, wenn ein Distributor sich seinem zugesagten Minimum oder Maximum nähert
  • Abruf-Preisgestaltung an die Rahmen-Bedingungen gebunden, nicht an aktuelle Listenpreise
  • Jahresend-Abgleichberichte für Take-or-Pay-Klauseln

Distributor-Rep-Auftragserfassung

Ihr eigener Außendienst-Mitarbeiter erfasst die Bestellung im Auftrag des Distributors.

  • Rep loggt sich ein, wählt den Distributor-Account, erfasst die Bestellung
  • Vertragspreise des Distributors gelten, nicht Listenpreise
  • Rep-Credit-Zuordnung für die Vertriebsprovisionsberechnung
  • Bestellung zur Distributor-Bestätigung weitergeleitet, wenn die Richtlinie es erfordert
  • Verbreitetes Muster auf Messen, bei Kundenbesuchen, technischen Vertriebsterminen
  • Vollständiger Audit-Trail: Rep, Distributor, Lieferadresse, Zuordnungscode

Deal-Registrierungs-Erfassung

Ein Distributor meldet einen Interessenten — noch keine Bestellung, aber ein zukünftiges Commitment.

  • Distributor reicht Interessenten ein: Projektname, Endkunde, geschätzter Wert, Produkte
  • 60- bis 90-tägige Exklusivität gewährt (konfigurierbar nach Partner-Tier)
  • Konflikterkennung gegen bestehende Registrierungen und Ihre Direktvertriebs-Pipeline
  • Genehmigungs-Routing zum Channel-Manager mit automatischem Verfall bei Untätigkeit
  • Konvertiert in ein Angebot, dann in eine Bestellung, wobei der Deal-Reg-Rabatt erhalten bleibt
  • Eigenständiger Workflow, getrennt von regulären Bestellungen — in PRM-artigen Reports nachverfolgt

Distributor-API + Webhooks

Für Distributoren mit Engineering-Teams, die direkt integrieren möchten.

  • Gleiche REST-Oberfläche wie B2B-Direkt, aber auf Distributor-Berechtigungen beschränkt
  • API-Schlüssel pro Distributor mit Widerruf und Rotation
  • ATP- und Pricing-Endpunkte spiegeln distributor-spezifische Vertragsbedingungen wider
  • Webhook-Callbacks zu Auftragsstatus, Rahmen-Abruf-Verbrauch, Deal-Reg-Statusänderungen
  • Verbreitet bei Master-Distributoren, die ihr eigenes E-Commerce-Frontend betreiben
  • Dokumentiertes Schema mit Sandbox-Tenant für Distributor-Entwicklungsarbeit

Was nach dem Eingang passiert

Unabhängig davon, über welchen Kanal eine Bestellung eingetroffen ist — ein Amazon SP-API-Pull, ein geparstes PDF aus einem Posteingang, eine EDI 850 von einem Tier-A-Distributor, eine cXML-Bestellung von Coupa — jeder Auftrag landet in derselben Orchestrierungs-Warteschlange.

Routing-Regeln greifen: Lagerauswahl nach SKU und Lieferadresse, Allokation gegen den vorhandenen Bestand, Versandmethoden-Auswahl nach Service-Level und Zone, Betrugs- und Adressvalidierung. PackScan kommissioniert und packt mit Barcode-Verifizierung. BatchTrack stempelt Chargen-, Serien- und Verfallsdaten auf den Sendungsdatensatz. ShipX vergleicht Tarife über Carrier hinweg und druckt das Label. Tracking wird zurück zum ursprünglichen Kanal synchronisiert — die Amazon Orders API, die WooCommerce-Seite, der cXML ShipNoticeRequest, die EDI 856.

Die Eingangsmethode bestimmt das Protokoll auf der Leitung. Danach ist jeder Auftrag dieselbe Art von Objekt innerhalb der Plattform.

Channel-Mix auf einen Blick

Die Eingangsmethoden, der typische Implementierungsaufwand und wer sie tatsächlich nutzt.

Dimension D2C / Multi-Channel B2B Direkt Distributor-Netzwerk
Primäre Eingangsmethoden Amazon SP-API (amazon.de), Otto Market Partner-API, Kaufland Marketplace API, Zalando Partner (demnächst), WooCommerce REST, eBay Trading API, Shopware 6, Shopify (demnächst), Custom-Storefront-REST REST API, E-Mail-PO-Erfassung, gehostetes B2B-Portal, EDI 850/855/856/810/820, cXML- und OCI-Punchout, CSV-Upload Geschütztes Distributor-Portal, EDI 850, Rahmen-PO-Abrufe, Distributor-Rep-Auftragserfassung, Deal-Registrierung, Distributor-API
Authentifizierungsmodell Vom Marktplatz ausgestellte OAuth- und API-Schlüssel OAuth 2.0, EDI-VAN-Credentials, AS2-Zertifikate, cXML-Shared-Secrets Credentials pro Partner mit Vertragsdurchsetzung
Preislogik Listenpreis oder Marktplatz-Tier-Preisgestaltung Account-basierte Vertragspreise, Volumen-Tier-Staffelungen Vertragspreise pro Distributor, Rahmen-PO-Bedingungen, Deal-Reg-Rabatte
Typischer Implementierungsaufwand Tage bis wenige Wochen pro Marktplatz; SP-API-Zertifizierung verlängert die Zeit für Amazon Stunden für REST, Wochen für Portal-Rollout, 4–12 Wochen für EDI oder Punchout pro Käufer Wochen für Portal-Rollout, laufendes Onboarding pro Distributor-Vereinbarung
Wer sie nutzt Marktplatz-Verkäufer, D2C-Marken, Hersteller mit eigenem E-Commerce Hersteller, die an Enterprise, Behörden, Healthcare, große Industrieeinkäufer verkaufen Hersteller mit Channel-Programmen — Tier-A-Master, regionale Partner, VARs
Vergleichbare Systeme Xentral, plentymarkets, Billbee, Afterbuy, JTL-Wawi BigCommerce B2B, OroCommerce, Shopify B2B, Adobe Commerce, Salesforce CPQ Salesforce PRM, Impartner, ZINFI, Channeltivity
OrderHUBx-Seite D2C / Multi-Channel B2B Direkt Distributor-Netzwerke

Erzählen Sie uns von Ihrem Channel-Mix

Marktplatz, gehostetes Portal, EDI-Käufer, Punchout-Anforderung oder alle vier auf einmal — wir bilden Ihre Eingangsmethoden auf der OrderHUBx-Plattform ab und geben Ihnen einen realistischen Implementierungsfahrplan.