Réception : lire les étiquettes aussi finement que l’article l’exige

À la réception d’un négociant, des caisses de pièces démontées arrivent chaque jour. Pour une pièce de frein, le numéro suffit ; pour un calculateur, les versions matérielle et logicielle comptent. Tout analyser produit des informations inutiles ; ressaisir stocke des fautes de frappe.

Le Hub propose trois profondeurs de lecture. Ce cas utilise les deux plus légères : on vérifie d’abord qu’un numéro est lisible et où il se trouve, puis on ne lit que les numéros. L’analyse complète reste réservée aux pièces dont la valeur dépend des variantes et versions.

Ce que ce cas suppose

• Une photo nette de l’étiquette. Les lectures prennent une adresse d’image accessible ; le flou coûte plus qu’une seconde photo.
• Une règle sur les pièces nécessitant l’analyse complète. Calculateurs, feux et pièces à variantes en font partie, les pièces d’usure rarement.
• Le constructeur, s’il est connu. La normalisation le prend comme contexte constructeur optionnel.
• Un système de stock par groupes. Le catalogue VDI 4081 fournit les groupes ; l’affectation par pièce vient des données OE.
• Le droit d’interroger le véhicule. Par l’appel, vous confirmez être détenteur, propriétaire ou mandaté de façon prouvée, ou autrement habilité en droit, et utiliser le numéro de châssis exclusivement pour la finalité licite indiquée.

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. Vérifier qu’un numéro existe. POST /scanner/label/basic répond par hasPartNumber et where — sur l’étiquette ou sur la pièce elle-même. Si aucun n’est lisible, une lecture plus poussée de cette image ne vaut rien ; une nouvelle photo, si.
2. Lire seulement les numéros. POST /scanner/label/extract-partnumbers renvoie partNumbers — numéros de pièce et de référence, sans constructeur, version ni variante. Pour l’essentiel d’une réception, c’est tout ce qu’il faut.
3. Valider le numéro. GET /parts/oe/normalize prend oeNumber et en option manufacturer et répond par status, lookupKey et normalizedOeNumber. C’est ici qu’une chaîne relevée devient un numéro exploitable.
4. Identifier la pièce. POST /parts/identify met en balance customerOeNumbers, labelReadings et descriptions et répond par une correspondance confirmée, des candidats ou aucune correspondance. C’est à cette étape qu’un numéro client et une lecture incohérents apparaissent.
5. Consulter le groupe de stock. GET /vdi renvoie le catalogue VDI 4081 publié avec stand, mainGroups et entries — par entrée code, mainGroup, weight, qualityGroup et possibleInstallationLocations, par pages avec limit et offset. Les affectations OE ne font pas partie de cet appel ; le groupe d’une pièce vient des données OE.

curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: wareneingang-kiste-17-teil-3' \
  -d '{"imageUrl":"https://example.com/etikett.jpg","quality":"enhanced"}' \
  'https://api.tapinomahub.com/scanner/label/extract-partnumbers'

Ce que l’on obtient

Au final, les pièces sont stockées avec un numéro validé et un groupe homogène, et l’analyse poussée n’a servi que là où elle fixe la valeur d’une pièce. Une étiquette sans numéro lisible se remarque au début, non chez le client.

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-hub). Tous les cas d’usage classés par surface et par rôle : aperçu des cas d’usage.