Qué es
El SKU (Stock Keeping Unit) es la unidad mínima e indivisible con la que un sistema de gestión identifica una referencia de inventario. No es lo mismo que un producto comercial: un producto puede tener decenas de SKUs si se vende en varias variantes (talla, color, formato, lote, ubicación). Cada SKU tiene un código único, una unidad de medida, un coste y una política de aprovisionamiento propios.
La distinción importa porque toda la operativa de almacén, compra y planificación se ejecuta a nivel de SKU, no de producto. Cuando se dice “tengo 1.200 unidades de la camiseta X” se está agregando información de SKUs distintos (talla S, M, L, XL en negro, blanco, azul…) que se gestionan por separado en cualquier ERP serio. Esa granularidad es la que permite calcular puntos de reorden, rotaciones y costes por referencia con sentido.
Un SKU bien definido tiene tres atributos no negociables:
- Unicidad: dos artículos con cualquier diferencia operativa (variante, proveedor, ubicación) son SKUs distintos. Si dos referencias pueden venderse o consumirse indistintamente, son el mismo SKU.
- Estabilidad: el código no cambia durante la vida útil de la referencia. Cambiarlo rompe históricos de venta, previsiones y trazabilidad.
- Codificación legible: el código debería decir algo sobre el artículo (familia, variante) sin convertirse en una descripción larga. Códigos completamente opacos generan errores de picking; códigos demasiado parlantes generan errores cuando cambia la categorización.
Cómo se estructura un SKU
No existe un estándar universal — cada empresa diseña su nomenclatura — pero las convenciones que funcionan en BC suelen seguir este patrón:
[Familia]-[Subfamilia]-[Producto]-[Variante]-[Atributo]
Ejemplo: TEX-CAM-CAM001-NEG-L para una camiseta (TEX = textil, CAM = camisetas, CAM001 = modelo, NEG = negro, L = talla L). Lo importante no es el formato exacto sino que la lógica sea consistente y escalable: que no necesites reformular toda la codificación cuando metas una nueva familia.
Tres reglas prácticas que aplicamos en auditorías:
- Bloques de longitud fija por nivel. Evita códigos donde el separador es la única pista del nivel.
- No mezclar identificadores con atributos cambiantes. El precio, el proveedor y la ubicación no van en el SKU: cambian.
- Códigos cortos para SKUs de alta rotación. Si el operario teclea el código 200 veces al día, cada carácter cuenta.
Cómo lo gestiona Business Central + dvstock
Business Central trabaja con SKUs a través de tres conceptos enlazados: el Item (referencia base), las Item Variants (variantes: talla, color) y el Stockkeeping Unit propiamente dicho (combinación de Item + variante + ubicación + dimensión). Esa estructura permite, por ejemplo, que la misma camiseta talla L tenga políticas distintas en el almacén de Zaragoza y en el de Barcelona.
Lo que BC nativo deja a medias:
- No segmenta automáticamente por matriz ABC-XYZ. Trata a todos los SKUs por igual en la planificación. Para un catálogo de 5.000 referencias, eso significa que el SKU A (alto valor, alta rotación) recibe la misma atención que el SKU C-Z (residual, errático).
- No detecta SKUs huérfanos. Referencias creadas para una promoción de hace cuatro años, sin movimientos pero con stock, que generan coste de almacén invisible.
- No alerta sobre proliferación. Catálogos que crecen un 15% anual sin que nadie revise si los SKUs nuevos canibalizan a los antiguos.
dvstock, nuestra extensión sobre BC desarrollada desde 2003 como Microsoft Solutions Partner en Business Central, complementa el SKU de BC con:
- Clasificación automática ABC-XYZ por valor y variabilidad (ver análisis ABC).
- Detección de SKUs zombi: cero movimientos en N meses con stock vivo. Propuesta de liquidación o transferencia.
- Auditoría de duplicados: dos SKUs con descripciones similares y proveedor idéntico que probablemente deberían ser uno.
- KPIs por SKU: rotación, DIO, margen, contribución a la rotura. Ver extensión dvstock.
Errores frecuentes
- Crear un SKU nuevo en lugar de una variante. Cuando una camiseta sale en color nuevo, se crea otra referencia “padre” en lugar de añadir una variante al SKU existente. Resultado: histórico fragmentado y previsiones imposibles.
- Reutilizar códigos de SKUs descatalogados. El código de una referencia muerta se asigna a una nueva. Trazabilidad rota y confusión en reportes históricos.
- No documentar la nomenclatura. El responsable que diseñó el sistema de codificación se fue, y el siguiente inventa códigos sobre la marcha. En tres años el catálogo es una sopa de letras.
- Confundir SKU con EAN/GTIN. El EAN es el código de barras estandarizado para escaneo en punto de venta; el SKU es el identificador interno. Pueden coincidir, pero no es obligatorio y mezclar ambos campos rompe integraciones.
- No revisar la salud del catálogo. Un catálogo que crece sin auditoría periódica acumula SKUs zombi, duplicados y referencias mal categorizadas. La regla de oro: el 5-10% del catálogo se revisa cada año.
Un SKU bien definido es la base sobre la que se construye toda la planificación. Si la unidad mínima de gestión es ambigua, ningún algoritmo posterior compensa el error.