La plupart des catalogues ne comptent qu'un seul code : le SKU. Cela fonctionne jusqu'au jour où le fournisseur de votre acheteur utilise ses propres codes, où le système d'achats de votre plus gros client attend un troisième code, et où l'ERP interne vieux de vingt ans que vous êtes en train de mettre à la retraite n'a toujours pas été décommissionné.
C'est la réalité de la distribution. Les produits circulent d'un système à l'autre, et chaque système possède sa propre convention de nommage. La facture du fournisseur indique « FAN-450-B ». Votre entrepôt l'étiquette « FAN450 ». Le portail d'achats du client attend « FAN-450-BLACK ». Et l'ERP hérité — celui qui tourne depuis 2003 et que personne n'ose éteindre — l'appelle toujours « ELEC-FAN-0450 ». Quatre codes. Un seul produit. Et si votre outil de devis ne comprend que l'un d'eux, vous traduisez manuellement les trois autres chaque jour.
Les quatre colonnes
Le Product de Quotery contient sku, import_code, internal_code et export_code. Chacun est indexé avec un trigramme GIN pour une recherche rapide en sous-chaîne. Chacun peut être recherché séparément ou ensemble.
L'index par trigrammes est le héros discret de cette architecture. Un index B-tree standard répond à la question « cette chaîne exacte correspond-elle ? », mais pas à « cette chaîne apparaît-elle quelque part dans ce champ ? » Avec un trigramme GIN, une recherche de « FAN450 » fait correspondre « FAN-450-B », « FAN450BLK » et « ELEC-FAN-0450 » — le tout en quelques millisecondes. C'est important, car les documents que vos clients envoient utilisent rarement le format exact de vos codes. Ils ajoutent des tirets, suppriment des préfixes, concatènent avec des couleurs. L'index par trigrammes absorbe cette variance sans obliger l'utilisateur à apprendre les expressions régulières.
Pourquoi l'importation IA s'y intéresse Lorsque l'importateur IA traite une ligne, il vérifie l'ensemble des quatre colonnes à la recherche d'une correspondance exacte avant de demander au modèle de raisonner sur le produit. C'est la différence entre une importation déterminée à 99 % et une importation qui brûle des tokens sur des problèmes déjà résolus.
Chaque correspondance déterministe permet d'économiser environ 200 à 500 tokens et 500 ms de latence. Sur une importation de 20 lignes, si 14 lignes correspondent de manière déterministe, l'étape IA ne traite que 6 lignes au lieu de 20 — soit une réduction de 70 % du coût et de la latence. Et les correspondances déterministes sont garanties correctes. Les correspondances IA, elles, sont probabilistes. Chaque ligne que vous pouvez résoudre sans le modèle est une ligne que vous n'avez pas à relire.
Favorable à la migration
Un client qui quitte un système hérité peut déverser ses anciens codes dans internal_code, mettre en place de nouveaux SKU, et laisser l'importateur faire le pont jusqu'à ce que les anciens codes s'estompent.
La migration est la phase la plus risquée de tout changement de système. Les anciens codes ne disparaissent pas du jour au lendemain : les fournisseurs continuent de les envoyer, les clients continuent de commander par ces codes, et les catalogues imprimés continuent de s'y référer. En conservant les anciens codes vivants dans internal_code pendant que le nouveau système de SKU prend le relais, la transition reste progressive et réversible. Lorsque le dernier fournisseur passera au nouveau code et que le dernier client cessera d'utiliser l'ancien, vous pourrez cesser de renseigner internal_code. Mais jusque-là, le pont reste en place.
DHDTech.io