Ein Teil gleichzeitig im Shop und auf mehreren Marktplätzen anzubieten erhöht Reichweite, aber auch das Risiko eines Überverkaufs. Bei einem Gebrauchtteil ist die verfügbare Menge oft exakt eins; bei Neuteilen können Lieferantenbestand, eigener Bestand und Reservierungen auseinanderlaufen. Deshalb braucht jeder Kanal dieselbe verfügbare Menge aus einem führenden System.
Architektur ohne konkurrierende Lager
- Das ERP oder Warenwirtschaftssystem ist die einzige Quelle für physischen Bestand, Reservierungen und Verkaufsstatus.
- Jeder Artikel erhält eine interne SKU; OE-/IAM-Nummern, Zustand und Fahrzeugzuordnung sind Stammdaten, nicht der Bestandsschlüssel.
- Marktplatz-Adapter veröffentlichen Angebote und nehmen Verkaufs-, Storno- und Retourenereignisse entgegen.
- Reservierungen reduzieren die verfügbare Menge sofort; endgültiger Verkauf und Rückabwicklung werden als eigene Ereignisse verbucht.
- Ein regelmäßiger Abgleich erkennt verlorene Webhooks, gesperrte Angebote und abweichende Mengen.
tapinomahub-Prozess und öffentliche APIs
- Teilenummer vom Etikett mit
POST /scanner/label/extract-partnumberserfassen und überGET /parts/oe/normalizenormalisieren. - OE-Teil, Fitment, Referenzfamilie und Ersetzungen mit
GET /parts/oe/{oeNumber}abgleichen. - IAM-Referenzen über
GET /parts/oe/{oeNumber}/aftermarket-referencesergänzen. - Kanaltexte mit
GET /parts/oe/{oeNumber}/seound bei BedarfGET /translation/translationsvorbereiten. - Angereicherten Datensatz an das ERP zurückgeben; dieses veröffentlicht über die jeweilige Marktplatz-API und bleibt Bestandsführer.
- Verkauf im ERP atomar reservieren und anschließend alle anderen Kanäle über deren APIs auf Menge null beziehungsweise die neue verfügbare Menge setzen.
Fehlerfälle, die vor dem Start getestet werden müssen
- Zwei nahezu gleichzeitige Verkäufe desselben Einzelstücks
- Webhook kommt doppelt, verspätet oder gar nicht an
- Marktplatz akzeptiert Zustandswert, Kategorie oder Fahrzeugkompatibilität nicht
- Lieferantenbestand fällt zwischen Bestellung und Bestätigung aus
- Retoure ist eingegangen, aber noch nicht erneut verkaufsfähig
- Teilnummer wurde ersetzt, während aktive Angebote die alte Referenz verwenden
Quellen und Rechtsgrundlagen
Häufige Fragen
Soll tapinomahub der zentrale Bestand sein?
Nein. Die öffentliche API reichert Fahrzeug- und Teiledaten an. Bestand, Reservierung und Verkauf sollten im ERP oder einer spezialisierten Commerce-Plattform geführt werden.
Reicht minütliches Polling gegen Überverkäufe?
Bei Einzelstücken oft nicht. Verkaufsereignisse sollten sofort verarbeitet werden; Polling oder Abgleichläufe bleiben als Sicherheitsnetz notwendig.
Funktioniert der Prozess auch für Neuteile?
Ja. Zusätzlich müssen Lieferantenbestand, Beschaffungszeit, Mindestbestand und noch nicht bestätigte Bestellungen in die verfügbare Menge einfließen.
