Du poste de démontage à la vente — la validation avant le prix

Au poste de démontage, un phare est déposé. Il paraît impeccable, et un collègue veut le publier aussitôt. Mais personne n’a encore décidé s’il peut être vendu comme pièce réutilisable — et c’est précisément cette décision qu’on demande d’abord lors d’une réclamation ou d’un contrôle.

La chaîne s’étend sur trois surfaces et fixe l’ordre : l’évaluation de réemploi dans Compliance précède la requête de prix et de marketplace dans le Hub, et c’est seulement ensuite que Commerce crée un article avec offre. Qui respecte cet ordre ne crée aucune offre sans validation documentée.

Ce que ce cas suppose

• Une personne compétente pour l’évaluation. L’évaluation de réemploi est réalisée par une personne connectée dans le rôle compétent ; une clé API ne suffit pas.
• Une étiquette lisible sur la pièce déposée. La référence OE vient de la pièce, non de la mémoire.
• Une connexion raccordée pour la vente. L’offre renvoie à une connexion et à une règle de prix.
• Votre propre référence article. L’article de catalogue porte votre merchantSku, l’offre la pièce en stock concrète.

Le déroulement

Le tableau indique pour chaque étape l’appel compétent et ce qui existe ensuite. La justification de l’étape figure en dessous.

Pourquoi chaque étape est nécessaire

1. Évaluer le réemploi. POST /compliance/parts/{id}/assessments prend result, reuseSafetyStatus, condition, defects, tests, materials et les preuves. La sécurité de réemploi est une déclaration propre, distincte de l’état — et une personne connectée réalise l’évaluation.
2. Lire le numéro. POST /scanner/label/extract-partnumbers renvoie les partNumbers de l’étiquette de la pièce déposée. Le numéro vient de la pièce elle-même, non de la liste de pièces du véhicule donneur.
3. Évaluer le prix. GET /parts/oe/{oeNumber}/price avec condition used renvoie une évaluation indicative avec min, max et average. Ce n’est pas une garantie de prix.
4. Produire les données marketplace. GET /parts/oe/{oeNumber}/seo renvoie content.ebayTitle, categoryId et itemSpecifics. Les données techniques deviennent texte de vente sans chercher de catégorie.
5. Créer l’article. PUT /commerce/v1/catalog/items/{catalogItemId} enregistre la version canonique avec merchantSku, condition et identifiers. L’article décrit, la pièce en stock existe — les deux restent séparés.
6. Préparer l’offre. PUT /commerce/v1/offers/{offerId} relie stockItemId, connectionId, price et pricingPolicyId. publicationState accepte draft, ready, paused et withdrawn ; le contrat ne décrit pas l’effet de ces états. Dans l’exemple, l’offre est transmise en draft.

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>'

Ce que l’on obtient

Il reste une offre adossée à une décision de réemploi documentée par une personne nommée, un numéro lu sur la pièce, une base de prix traçable et un texte marketplace. Le phare n’est pas vendu parce qu’il avait bonne allure, mais parce qu’il a été validé.

Où cela figure dans la documentation

Les listes de champs contractuelles, les codes d’erreur et les réponses d’exemple se trouvent dans le contrat OpenAPI de cette surface, à l’adresse docs.tapinomahub.com (tapinoma-compliance, tapinoma-hub, tapinoma-commerce). Tous les cas d’usage classés par surface et par rôle : aperçu des cas d’usage.