Varios códigos de barras Shopify: EAN, UPC y GTIN

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

Shopify ahora permite asociar hasta 20 códigos de barras al mismo producto o variante. Es un cambio pequeño en el panel, pero importante para catálogos donde el mismo artículo llega de proveedores distintos, usa identificadores diferentes entre retail y marketplaces o necesita gestionar a la vez EAN, UPC, GTIN, ISBN, ASIN y códigos internos.

Shopify anunció la novedad el 8 de septiembre de 2026. No hace falta recrear los productos existentes: el código que ya estaba guardado permanece en la primera posición. Lo que sí conviene revisar son las integraciones construidas alrededor de un único campo de código de barras.

Qué cambia en el catálogo de Shopify

Hasta ahora una variante tenía, en la práctica, un identificador de código de barras principal. Cuando el mismo artículo tenía otros códigos, era habitual guardarlos en metafields, hojas de cálculo o sistemas externos.

Shopify permite ahora añadir varios códigos directamente al producto o a la variante. Cada uno puede clasificarse como UPC, EAN, ISBN, GTIN o ASIN; para identificadores internos que no siguen uno de esos estándares se puede usar Custom.

Shopify documenta un máximo de 20 códigos de barras por producto o variante. El mismo valor no puede repetirse dentro del mismo producto o variante. Cuando eliges un tipo estándar, Shopify valida el valor según las reglas de ese formato.

El primer código de barras sigue siendo importante

Tener varios códigos no significa que todas las superficies consuman el conjunto completo. El changelog oficial indica que, cuando un canal o una integración espera un solo código, sigue utilizando el primer código de barras asociado a la variante.

Ese es el primer punto que revisaría en una tienda ya operativa. Si el código principal alimenta un marketplace, un feed, un flujo de etiquetas o un ERP, cambiar el orden puede afectar a sistemas externos aunque el producto en Shopify parezca igual.

Cuándo varios códigos resuelven un problema real

Varios proveedores: el mismo artículo puede llegar con códigos distintos según el proveedor o el lote.
Marca propia: pueden convivir el código del fabricante y un EAN del propio brand.
Marketplaces: el mismo artículo puede necesitar también un ASIN u otro identificador del canal.
Retail y POS: embalajes o mercados distintos pueden mostrar códigos diferentes para la misma variante.
Migraciones y consolidación: los identificadores históricos pueden seguir asociados a la variante sin crear productos duplicados solo para mantener la búsqueda.

No usaría los códigos de barras como contenedor genérico para cualquier dato empresarial. SKU, barcode y atributos de producto resuelven trabajos diferentes. Si el dato describe una característica o una relación de catálogo, puede ser más correcto usar metafields o Metaobjects. Lo explico en la guía sobre catálogos Shopify complejos con variantes, metafields y Metaobjects.

CSV: la columna ahora es “Barcodes”

Shopify también ha actualizado la importación y exportación de productos. La columna del CSV es ahora Barcodes y puede contener varios valores separados por punto y coma.

La documentación muestra además cómo indicar el tipo, por ejemplo gtin:00012345678905; upc:012345678905; INTERNAL-123. Un valor sin tipo se importa como Custom.

Hay un detalle operativo importante: un CSV no puede contener a la vez la antigua columna singular Barcode y la nueva Barcodes. Shopify indica que un archivo con ambas falla al importarse. Si un proceso automático genera los CSV, conviene actualizar la plantilla antes de la siguiente importación masiva.

POS puede encontrar la variante con cualquiera de sus códigos

Shopify POS permite buscar y escanear usando cualquiera de los códigos asociados a la variante. Shopify introdujo este comportamiento en POS v11.14: si el código escaneado está vinculado a la variante, POS puede encontrar el mismo artículo.

En operaciones omnicanal esto puede eliminar búsquedas manuales y duplicaciones. Aun así, es importante probar los lectores reales y evitar identificadores ambiguos entre artículos diferentes.

Si el problema va más allá del identificador y afecta a disponibilidad o routing entre ubicaciones, hay que tratarlo por separado. El inventario multiubicación y el routing de pedidos en Shopify son otra capa de la arquitectura.

El punto crítico: ERP, apps e integraciones custom

Para una tienda que usa solo Shopify Admin y POS, el cambio es relativamente directo. El riesgo aumenta cuando catálogo e inventario se sincronizan con un ERP, PIM, 3PL, marketplace o app custom.

El changelog para desarrolladores señala un problema concreto de compatibilidad: una integración que siga leyendo solo ProductVariant.barcode ve el primer código, pero no recibe una señal automática de que existen códigos adicionales. Eso puede generar pérdida silenciosa de información durante la sincronización.

Shopify ha introducido la nueva conexión barcodes y ha marcado el antiguo campo barcode como deprecated. El changelog para desarrolladores vincula la nueva gestión a la API 2026-10 y señala que la fecha futura de retirada se anunciará con el preaviso de una versión API completa.

Por eso no actualizaría una integración solo porque el Admin muestre más códigos. Primero comprobaría la versión API, qué campos lee y escribe el software, cómo interpreta el primer código y si una escritura sustituye el conjunto completo.

Cuidado al escribir códigos mediante API

Hay dos detalles que pueden provocar regresiones. Cuando se usa el nuevo input múltiple, Shopify indica que enviar barcodes sustituye todo el conjunto de la variante. Una integración que añade un código debe conservar también los que deban permanecer.

Además, un mismo input de variante no puede establecer simultáneamente el antiguo barcode y el nuevo barcodes. Una migración API necesita por tanto una ruta de escritura explícita y pruebas de regresión sobre la sincronización del catálogo.

Secuencia práctica antes de desplegarlo

Mapear todos los consumidores actuales del barcode: Admin, POS, feeds, marketplaces, ERP, 3PL, apps y CSV.
Decidir qué código debe permanecer en primera posición.
Añadir unos pocos casos reales de prueba.
Verificar búsqueda y escaneo en Admin/POS cuando corresponda.
Exportar el CSV y revisar la nueva columna Barcodes.
Comprobar las integraciones que leen o escriben datos de catálogo.
Solo después extender el cambio al resto del catálogo.

En un catálogo con miles de variantes evitaría una actualización masiva antes de completar al menos un ciclo completo de lectura, modificación, exportación y sincronización. La función nativa elimina workarounds, pero no puede saber qué identificador considera primario cada sistema externo.

Qué no cambia

Los códigos existentes siguen en su sitio y no hay una migración obligatoria si un único código por variante ya cubre el caso de uso. Es capacidad adicional, no una razón para reorganizar el catálogo sin necesidad.

El criterio útil es operativo: añadir códigos cuando eliminan duplicaciones, mejoran la fiabilidad del escaneo o permiten que sistemas distintos reconozcan la misma variante sin crear copias artificiales del producto.