Vom Demontageplatz in den Verkauf — erst die Freigabe, dann der Preis

Auf dem Demontageplatz wird ein Scheinwerfer ausgebaut. Er sieht einwandfrei aus, und ein Kollege will ihn sofort einstellen. Ob er als wiederverwendbares Teil verkauft werden darf, hat aber noch niemand entschieden — und genau diese Entscheidung ist es, die bei einer Reklamation oder einer Prüfung als Erstes gefragt wird.

Die Kette zieht sich über drei Flächen und legt die Reihenfolge fest: Die Wiederverwendungsbewertung in der Compliance-Fläche steht vor der Preis- und Marktplatzabfrage im Hub, und erst danach entsteht in Commerce ein Artikel mit Angebot. Wer diese Reihenfolge einhält, legt kein Angebot ohne dokumentierte Freigabe an.

Was dieser Fall voraussetzt

• Eine sachkundige Person für die Bewertung. Die Wiederverwendungsbewertung nimmt eine angemeldete Person in der zuständigen Rolle vor; ein API-Schlüssel genügt nicht.
• Ein lesbares Etikett am ausgebauten Teil. Die OE-Nummer kommt vom Teil, nicht aus der Erinnerung.
• Eine angebundene Verbindung für den Verkauf. Das Angebot verweist auf eine Verbindung und eine Preisregel.
• Eine eigene Artikelnummer. Der Katalogartikel trägt Ihre merchantSku, das Angebot das konkrete Lagerstück.

Der Ablauf

Die Tabelle nennt je Stufe den zuständigen Aufruf und das, was danach vorliegt. Die Begründung, warum die Stufe nicht übersprungen werden kann, steht darunter.

Warum jede Stufe nötig ist

1. Die Wiederverwendung bewerten. POST /compliance/parts/{id}/assessments nimmt result, reuseSafetyStatus, condition, defects, tests, materials und Belege. Die Wiederverwendungssicherheit ist eine eigene Aussage, getrennt vom Zustand — und die Bewertung nimmt eine angemeldete Person vor.
2. Die Nummer lesen. POST /scanner/label/extract-partnumbers gibt die partNumbers vom Etikett des ausgebauten Teils zurück. Die Nummer kommt vom Teil selbst, nicht aus der Teileliste des Spenderfahrzeugs.
3. Den Preis bewerten. GET /parts/oe/{oeNumber}/price mit condition used liefert eine indikative Bewertung mit min, max und average. Sie ist keine Preisgarantie.
4. Die Marktplatzdaten erzeugen. GET /parts/oe/{oeNumber}/seo liefert content.ebayTitle, categoryId und itemSpecifics. Aus Teiledaten wird Verkaufstext, ohne dass jemand eine Kategorie sucht.
5. Den Artikel anlegen. PUT /commerce/v1/catalog/items/{catalogItemId} legt die kanonische Fassung mit merchantSku, condition und identifiers ab. Der Artikel beschreibt, das Lagerstück existiert — beides bleibt getrennt.
6. Das Angebot vorbereiten. PUT /commerce/v1/offers/{offerId} verbindet stockItemId, connectionId, price und pricingPolicyId. publicationState kennt draft, ready, paused und withdrawn; die Wirkung dieser Zustände beschreibt der Vertrag nicht. Im Beispiel wird das Angebot als draft übermittelt.

curl -X PUT \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: angebot-scheinwerfer-88213' \
  -d '{"stockItemId":"<stockItemId>","connectionId":"<connectionId>","price":{"amountMinor":12900,"currency":"EUR"},"pricingPolicyId":"<pricingPolicyId>","publicationState":"draft","revision":"<revision>"}' \
  'https://commerce-preview.invalid/commerce/v1/offers/<offerId>'

Was am Ende vorliegt

Am Ende steht ein Angebot, hinter dem eine dokumentierte Wiederverwendungsentscheidung einer benannten Person steht, eine vom Teil gelesene Nummer, eine nachvollziehbare Preisgrundlage und ein Marktplatztext. Der Scheinwerfer wird nicht verkauft, weil er gut aussah, sondern weil er freigegeben ist.

Wo das in der Dokumentation steht

Die verbindlichen Feldlisten, Fehlercodes und Beispielantworten stehen im OpenAPI-Vertrag dieser Fläche unter docs.tapinomahub.com (tapinoma-compliance, tapinoma-hub, tapinoma-commerce). Alle Anwendungsfälle nach Fläche und Rolle geordnet: Übersicht der Anwendungsfälle.