Più barcode per variante Shopify: EAN, UPC e GTIN

Postazione e-commerce con laptop, scanner e pacchi etichettati con codici a barre per la gestione del catalogo Shopify

Shopify ora permette di associare fino a 20 barcode allo stesso prodotto o alla stessa variante. È una modifica piccola nell’interfaccia, ma importante per cataloghi che ricevono lo stesso articolo da fornitori diversi, usano codici differenti tra negozio fisico e marketplace oppure devono gestire insieme EAN, UPC, GTIN, ISBN, ASIN e codici interni.

La novità è stata annunciata da Shopify l’8 settembre 2026. Non richiede di ricreare i prodotti esistenti: il barcode già presente rimane al primo posto. Il punto da verificare, invece, è cosa succede nelle integrazioni che fino a ieri leggevano un solo campo barcode.

Cosa cambia nel catalogo Shopify

Fino a questa modifica una variante aveva, di fatto, un identificativo barcode principale. Quando lo stesso articolo arrivava con più codici, molti store finivano per tenere gli identificativi aggiuntivi in metafield, fogli esterni o sistemi gestionali.

Ora Shopify consente di aggiungere più barcode direttamente al prodotto o alla variante. Ogni codice può essere classificato con un tipo standard, tra cui UPC, EAN, ISBN, GTIN e ASIN; per identificativi interni che non seguono uno standard è disponibile anche il tipo Custom.

Shopify documenta un limite massimo di 20 barcode per prodotto o variante. Lo stesso valore non può essere duplicato all’interno dello stesso prodotto o della stessa variante. Quando assegni un tipo standard, Shopify valida il valore rispetto alle regole del formato previsto.

Il primo barcode resta importante

Avere più barcode non significa che tutte le superfici Shopify li trattino nello stesso modo. Il changelog ufficiale specifica che, quando un canale o un’integrazione si aspetta un solo barcode, continua a essere utilizzato il primo barcode associato alla variante.

Questo dettaglio è quello che controllerei per primo in uno store già operativo. Se il barcode principale alimenta un marketplace, un feed prodotto, un’etichetta o un gestionale, cambiare l’ordine dei codici può avere effetti a valle anche se il prodotto in Shopify sembra identico.

La regola pratica è semplice: usa il primo barcode come identificativo compatibile con i sistemi che leggono ancora un solo valore e tratta gli altri come identificativi aggiuntivi della stessa variante.

Quando più barcode risolvono un problema reale

La funzione è utile soprattutto quando una stessa variante ha più identità operative senza essere, dal punto di vista commerciale, un prodotto diverso.

Fornitori diversi: lo stesso articolo può arrivare con codici differenti a seconda del fornitore o del lotto.
Private label: puoi avere il codice del produttore e un EAN usato dal tuo brand.
Marketplace: un articolo può essere identificato anche con ASIN o altri codici richiesti da un canale esterno.
Retail e POS: confezioni o mercati differenti possono riportare codici diversi pur riferendosi alla stessa variante.
Migrazioni e consolidamento catalogo: identificativi storici possono restare associati alla variante senza creare prodotti duplicati soltanto per conservare la ricercabilità.

Non userei però i barcode come contenitore generico per qualsiasi codice aziendale. SKU, barcode e identificativi esterni rispondono a lavori diversi: se un dato serve a descrivere una caratteristica del prodotto o una relazione di catalogo, può essere più corretto usare metafield o Metaobjects. Ho approfondito questa distinzione nella guida sul catalogo Shopify complesso con varianti, metafield e Metaobjects.

CSV: la colonna è diventata “Barcodes”

Shopify ha aggiornato anche l’import/export prodotti. Nel CSV la colonna è ora Barcodes e può contenere più valori separati da punto e virgola.

La documentazione mostra anche la sintassi per indicare il tipo, per esempio gtin:00012345678905; upc:012345678905; INTERNAL-123. Un codice senza tipo viene importato come Custom.

C’è un controllo operativo importante: un CSV non può contenere contemporaneamente la vecchia colonna singolare Barcode e la nuova Barcodes. Shopify indica che un file con entrambe non viene importato. Se hai procedure automatiche che generano CSV, quindi, conviene aggiornare il template prima del prossimo import massivo.

POS può trovare la variante con uno qualsiasi dei barcode

Shopify POS supporta la ricerca e la scansione usando uno qualsiasi dei barcode associati alla variante. Shopify ha introdotto questo comportamento in POS v11.14: se il codice scansionato è uno degli identificativi collegati alla variante, POS può risalire allo stesso articolo.

Per un’attività omnicanale questo elimina diversi workaround: il personale non deve conoscere quale codice sia stato scelto come “principale” per trovare il prodotto. Resta comunque fondamentale evitare associazioni ambigue tra articoli diversi e testare il flusso con i lettori realmente usati nel punto vendita.

Se il problema è più ampio del singolo codice e riguarda disponibilità o instradamento tra sedi, va trattato separatamente. La gestione di inventario multi-magazzino e sedi Shopify rimane un livello diverso dell’architettura.

Il punto critico sono ERP, app e integrazioni custom

Per uno store che usa solo l’Admin e Shopify POS la novità è relativamente lineare. Il rischio aumenta quando catalogo e inventario vengono sincronizzati con ERP, PIM, 3PL, marketplace o app custom.

Nel developer changelog Shopify segnala un caso preciso: un’integrazione che continua a leggere soltanto il vecchio campo singolare ProductVariant.barcode vede il primo codice, ma non riceve automaticamente un segnale che ne esistono altri. Questo può produrre una perdita silenziosa di informazione nella sincronizzazione.

Shopify ha introdotto la nuova connessione barcodes e indica che il vecchio campo barcode è deprecato. Nel changelog per sviluppatori la nuova gestione è associata all’API 2026-10; Shopify ha annunciato che comunicherà in futuro la data di rimozione del campo precedente con il preavviso previsto per una versione API completa.

Quindi non aggiornerei una integrazione alla cieca soltanto perché il pannello Admin mostra più codici. Prima verificherei la versione API usata dal software, quali campi legge e scrive, come interpreta il primo barcode e se sostituisce l’intero set durante un aggiornamento.

Lo stesso controllo vale in una integrazione ERP o gestionale con Shopify: prima si definisce quale sistema è source of truth per ogni identificativo, poi si implementa la sincronizzazione.

Attenzione quando scrivi i barcode via API

La documentazione per sviluppatori aggiunge due dettagli che possono creare regressioni.

Primo: quando usi il nuovo input multiplo, Shopify indica che l’invio di barcodes sostituisce l’intero set della variante. Un’integrazione che vuole aggiungere un codice deve quindi conoscere anche quelli da mantenere, non limitarsi a inviare soltanto il nuovo valore.

Secondo: nello stesso input di variante non puoi impostare contemporaneamente il vecchio barcode e il nuovo barcodes. Durante una migrazione API serve quindi una scelta esplicita del percorso di scrittura e una regression sui flussi di catalogo.

Una procedura pratica prima di adottare la funzione

Per uno store già in produzione farei un controllo in questo ordine:

mappare dove viene usato oggi il barcode: Admin, POS, feed, marketplace, ERP, 3PL, app e CSV;
decidere quale codice deve restare in prima posizione;
aggiungere pochi casi reali su prodotti di test o su un campione controllato;
verificare ricerca e scansione in Admin/POS dove applicabile;
esportare il CSV e controllare la nuova colonna Barcodes;
verificare le integrazioni che leggono o scrivono il catalogo;
solo dopo estendere l’aggiornamento al resto del catalogo.

In un catalogo con migliaia di varianti eviterei un bulk update prima di avere verificato almeno un ciclo completo di lettura, modifica, esportazione e sincronizzazione esterna. La funzione nativa riduce i workaround, ma non può sapere quale identificativo il tuo ecosistema considera primario.

Cosa non cambia

I barcode già presenti restano validi e non serve una migrazione obbligatoria per continuare a usare Shopify. La novità aggiunge capacità, non richiede di riordinare il catalogo se un singolo barcode per variante copre già il tuo caso.

Questo è anche il criterio che userei per decidere se intervenire: non aggiungerei codici “per completezza”. Li aggiungerei quando eliminano una duplicazione, rendono più affidabile una scansione o permettono a sistemi diversi di riconoscere la stessa variante senza creare prodotti artificialmente separati.

Il criterio tecnico

La possibilità di avere più barcode rende il modello dati di Shopify più vicino a molti cataloghi reali. Ma il beneficio arriva solo se rimane chiaro quale identificativo è primario e quali sistemi devono conoscere l’intero set.

Per uno store semplice basta configurare correttamente i codici. Per un ecosistema con POS, marketplace e gestionale, invece, la modifica va trattata come un piccolo cambiamento di schema dati: mappa le dipendenze, aggiorna le integrazioni che leggono un solo valore e testa il read-back prima di fare modifiche massive.