Shopify permite acum mai multe coduri de bare pe o singură variantă, citite prin conexiunea barcodes și scrise prin productSet, productVariantsBulkCreate și productVariantsBulkUpdate. Câmpul vechi barcode e deprecat, dar funcționează în continuare. Problema reală nu e funcția nouă, ci integrările care citesc doar barcode și pierd restul identificatorilor fără să semnaleze nimic.

Comercianții vând des același produs sub mai multe identități: un UPC de la producător lângă un EAN de private label, un GTIN, un ISBN reeditat sau un ASIN pentru un marketplace. Până acum varianta avea o singură valoare, iar restul ajungeau în metafields, tag-uri sau în afara Shopify. Sursa: Shopify Changelog.

Ce se schimbă concret în API

Fiecare cod poate avea un tip declarat: UPC, EAN, ISBN, GTIN sau ASIN. Valorile sunt validate pe regulile standardului respectiv (caractere, lungime, prefix, cifră de control). Dacă nu declari tipul, valoarea e stocată exact cum ai trimis-o, ca să nu rupă datele existente.

Limitele sunt clare: maximum 20 de coduri per variantă, fiecare de până la 255 de caractere. Primul cod trimis e cel returnat de câmpul vechi barcode și apare primul în listă. Un input nu poate seta simultan barcode și barcodes. Trimiterea lui barcodes înlocuiește întregul set, deci trebuie să incluzi tot ce vrei să păstrezi.

Filtrul barcode din interogările products și productVariants caută acum în orice cod al variantei. Câmpul ProductVariant.barcode e deprecat, dar nimic nu se rupe azi: citirea returnează prima intrare, scrierea actualizează primul cod și lasă restul intacte, iar o valoare goală șterge primul cod și promovează următorul. Shopify anunță un termen de eliminare în viitor, cu o versiune completă de API ca preaviz.

Riscul de trunchiere silențioasă

Aici e miezul problemei. Odată ce adaugi un al doilea cod, orice integrare care citește doar barcode vede unul singur, fără niciun semnal că mai există altele. Nu primești eroare, nu primești warning. Primești o sincronizare incompletă.

Dacă aplicația ta trimite identificatori către un ERP, un marketplace, un POS sau un feed de furnizor, citirile trebuie mutate pe conexiunea barcodes. Altfel, fluxurile care depind de codul „greșit" pot eșua fără explicație. Nu e o eroare de API, e o eroare de arhitectură a integrării.

Atenție la formulare: nu avem dovezi că apar pierderi de bani, amenzi sau căderi de CPA din acest motiv. Vorbim despre un risc tehnic de sincronizare, nu despre o consecință comercială măsurată. O verificare incompletă a codurilor nu dovedește că o funcție lipsește, dovedește doar că nu ai acoperit toate cazurile.

Ce verifici în magazinele tale

Primul pas nu e codul nou, ci inventarul. Listează ce aplicații ating câmpul barcode: ERP, WMS, POS, feed-uri de produse, integrări de marketplace, scripturi interne. Pentru fiecare, notează dacă citește, scrie sau ambele.

Al doilea pas: testează. Creează o variantă de test cu două coduri, unul tipizat și unul liber. Verifică ce returnează fiecare integrare, ce ajunge în ERP și ce ajunge în feed. Nu presupune, măsoară.

Al treilea pas: decide ordinea. Dacă un marketplace cere obligatoriu un anumit cod, pune-l primul. Dacă un partener folosește câmpul vechi, ai grijă ca scrierea lui barcode să nu suprascrie codul de care depinde alt flux.

Ce înseamnă pentru tine

Dacă vinzi pe Shopify în România și ai un ERP local conectat, e momentul să întrebi furnizorul integrării ce câmp citește. Mulți conectori vechi merg pe barcode. Când adaugi un EAN de private label peste un UPC de producător, conectorul va vedea doar prima valoare.

Pentru un magazin care lucrează cu furnizori multiple pe același SKU, câștigul e real: identificatori diferiți trăiesc în sfârșit în același loc, nu în metafields greu de interogat. Pentru un magazin cu un singur cod per variantă, schimbarea e aproape invizibilă azi, dar devine relevantă în momentul în care conectezi un marketplace nou.

Echipa de ecommerce care lucrează cu date first-party are aici un caz clar de guvernanță a datelor. Dacă te interesează cum se leagă aceste baze de măsurare, vezi analiza despre date first-party ca sursă de venit în programmatic și despre Google Ads și Meridian GeoX pentru growth. Aceleași principii se aplică: dacă datele de bază sunt incomplete, nici măsurarea nu stă în picioare.

Miza practică pentru un operator român: auditul câmpului barcode înainte de a adăuga un al doilea cod. Nu e o sarcină de dezvoltator izolat, e o decizie de business. Ce cod folosește fiecare partener, ce cod trebuie să rămână pe prima poziție, ce integrare trebuie migrată mai întâi. Astea sunt întrebări la care răspunsul nu vine din documentație.

Ce rămâne incert și ce urmează

Sursa nu precizează data exactă a eliminării câmpului barcode. Spune doar că va fi anunțată într-o postare viitoare, cu o versiune completă de API ca preaviz. Asta lasă o fereastră de planificare, nu un termen. Orice plan care presupune o dată fixă ar fi o presupunere, nu un fapt.

Nu știm nici ce se întâmplă cu metafields existente care țin coduri suplimentare. Nu se spune nimic despre migrare automată. Deci e o decizie manuală: muți datele în barcodes sau le lași unde sunt și accepți riscul de duplicare. Recomandarea noastră e să documentezi fiecare sursă de identificator înainte de a muta ceva.

Un scenariu ipotetic, marcat ca atare: dacă ai 5.000 de variante cu coduri suplimentare în metafields și un marketplace cere ASIN, migrarea lentă poate însemna feed-uri parțiale pentru o perioadă. Nu e o predicție, e un caz de planificat. Verifică volumul real înainte de a estima efortul.

FAQ

Câmpul barcode mai funcționează? Da. E deprecat, dar funcționează complet azi. Citirea returnează primul cod, scrierea actualizează primul cod. Rămâne util pentru suprafețele nemigrate.

Ce se întâmplă dacă trimit barcodes fără tip? Valoarea e stocată exact cum ai trimis-o, fără validare. Datele neintegrate continuă să funcționeze ca înainte.

Câte coduri pot pune pe o variantă? Maximum 20, fiecare de până la 255 de caractere. Trimiterea setului înlocuiește tot ce exista, deci include ce vrei să păstrezi.

Concluzia ALLSoft Agency

AI-ul ajută la analiză și planificare: poate mapa rapid ce integrări ating câmpul barcode, poate genera listele de verificat, poate schița ordinea codurilor per partener. Dar decizia și execuția rămân umane. Un media buyer sau un operator ecommerce știe ce cod contează pentru ce canal, ce partener depinde de ce identificator și ce se rupe dacă prima poziție se schimbă.

Pasul concret îl face ALLSoft Agency: audităm fluxurile de date, stabilim ce integrări trebuie migrate și în ce ordine, apoi implementăm fără să rupem sincronizarea existentă. Fără hype, fără promisiuni de cifre inventate, doar verificare și execuție.

Notă editorială: articol adăugat retrospectiv la 2026-09-12, în ediția din 2026-09-11. Data ediției nu reprezintă data lansării anunțului.