Diseña un catálogo de productos con variantes y paquetes usando reglas claras de SKU, lógica de inventario y patrones de interfaz que eviten combinaciones erróneas y sobreventa.
Un catálogo parece simple cuando cada producto es un artículo con un precio y un número de stock. Añade color, talla, duración de suscripción o embalaje específico por región y esa simplicidad se rompe. Una sola tabla de “Productos” ya no responde preguntas básicas: ¿qué exacto estamos vendiendo y cómo lo registramos?
Los compradores también esperan que los detalles estén correctos. Quieren elegir opciones, ver el precio correcto de inmediato y saber si su elección puede enviarse hoy. Si la página dice “En stock” pero la talla seleccionada no está, la confianza cae rápido. Si el precio cambia sólo en el checkout, aparecen tickets de soporte y devoluciones.
Los paquetes añaden una segunda capa de complejidad porque parecen productos pero se comportan como reglas. Un “Kit de inicio” puede incluir una botella, una bomba y un juego de filtros. Su disponibilidad depende de las piezas, y tus costes e informes deben seguir teniendo sentido.
Señales de que tu catálogo empieza a fallar:
La solución es mayormente disciplina: un modelo de datos coherente y patrones de interfaz que hagan obvia la selección de opciones y la disponibilidad para clientes y equipo.
Cuando la gente dice “variantes”, a menudo mezcla varias ideas. Aclarar términos desde el principio facilita decisiones posteriores (esquema, UI, inventario).
La mayoría de equipos usan estas definiciones:
Los IDs también causan confusión en la práctica. Un ID interno es el que usa tu base de datos. Un SKU es tu código operacional (para picking, reabastecimiento e informes). Un código de barras (UPC/EAN) es lo que leen los escáneres. Un SKU puede tener múltiples códigos de barras (diferentes regiones) y algunos artículos no tienen ninguno.
Una buena regla para decidir si algo debe ser una variante vendible: si puede tener un precio distinto, inventario distinto, peso o reglas de envío distintas, trátalo como vendible. La misma camiseta en Talla M y Talla XL normalmente necesita contajes de stock separados, por eso deberían ser SKUs separados.
Antes de elegir un esquema, parte de las preguntas que el negocio debe responder cada día. Cuando alguien mira un artículo, ¿puedes decir con confianza: está disponible ahora, cuánto cuesta, cómo se enviará y qué reglas fiscales aplican?
Una forma útil de pensarlo es decidir dónde vive cada “dato”. Pon los hechos compartidos en el producto y los hechos que cambian en la variante (SKU). Si los mezclas, acabarás arreglando el mismo error en dos sitios.
Preguntas que suelen decidir campos a nivel producto vs a nivel variante:
Mantén una sola fuente de la verdad. Por ejemplo, no almacenes “precio” en producto y variante a la vez a menos que los roles estén claros (por ejemplo, el producto tiene MSRP y la variante el precio real de venta).
Planea para el cambio. Puedes añadir una nueva opción más adelante (como “Largo”), retirar una variante o fusionar SKUs tras cambios de proveedor. Esto va mejor cuando las variantes son registros de primera clase, no solo etiquetas.
Si construyes en AppMaster, un nombrado claro de entidades en el Data Designer facilita el mantenimiento cuando cambian los requisitos.
Un esquema limpio mantiene el catálogo comprensible cuando un producto simple se convierte en docenas de combinaciones vendibles. El objetivo es modelar las elecciones (lo que el comprador selecciona) separado de los ítems vendibles (lo que realmente almacenas y envías).
Un conjunto fiable de entidades:
La unicidad de las variantes es donde muchos catálogos fallan. El enfoque más seguro es normalizar: asegurar un OptionValue por Option para cada Variant y prevenir combinaciones duplicadas. Si quieres rendimiento, guarda una “clave de variante” computada como color=red|size=m (o un hash) en Variant y hazla única por Product.
Mantén los campos que cambian por combinación en Variant, no en Product: SKU, código de barras, precio, precio de comparación, coste, peso, dimensiones, estado (activo/descontinuado) e imágenes (una imagen principal o un pequeño set).
Para atributos personalizados (como “material” o “instrucciones de cuidado”), evita añadir columnas nuevas continuamente. Un campo JSONB en Product o Variant funciona bien en PostgreSQL, acompañado de una capa pequeña de validación en tu app.
Un SKU es un identificador para una unidad vendible que te comprometes a mantener estable. Debe responder a una pregunta: “¿Qué artículo exacto vendimos?” No debería intentar llevar tu nombre de marketing, todo el texto de opciones, temporada o una historia completa. Si lo sobrecargas, será difícil cambiar algo más tarde sin romper informes.
Decide pronto si los SKUs son asignados por humanos o generados. Los SKUs manuales son más seguros si ya tienes un ERP, códigos de barras o SKUs de proveedores que deben coincidir. Los SKUs generados son mejores cuando tienes muchas variantes y necesitas consistencia, pero solo si las reglas no cambian a mitad de año. Un punto intermedio común es un SKU base fijo que controlas más un sufijo corto generado para atributos de variante.
Reglas que se leen bien y sobreviven al crecimiento:
Los SKUs descontinuados no deben borrarse. márcalos inactivos, conserva su historial de precios y déjalos seleccionables en pedidos pasados, reembolsos e informes. Si reemplazas un SKU, guarda una referencia “reemplazado por” para que soporte pueda trazar qué ocurrió.
Reglas de validación previenen daños lentos: impón unicidad de SKU entre todos los ítems vendibles, permite solo letras, números y guiones, define longitud máxima clara (a menudo 20–32 caracteres) y reserva prefijos para casos especiales (por ejemplo, “BND-” para paquetes). En AppMaster, estas comprobaciones encajan como restricciones de datos más un Business Process que bloquee guardados cuando se rompa una regla.
El inventario se complica cuando el mismo “producto” puede significar muchas unidades vendibles distintas. Antes de escribir reglas, elige tu unidad de inventario: ¿controlas stock a nivel producto, variante o ambos?
Si los clientes eligen talla o color, el stock a nivel variante suele ser lo más seguro. Una camiseta puede estar “en stock” en general, pero la variante Small-Blue puede estar agotada. El nivel producto funciona para ítems donde las variantes no cambian lo que físicamente almacenas (por ejemplo, una licencia digital con distintos planes de facturación). Algunos equipos mantienen ambos: producto para informes y variante para ventas.
La prevención de sobreventa no es una bandera mágica sino estados claros. La mayoría de catálogos necesitan reservas (retener unidades brevemente para carritos o pedidos impagos), pedidos pendientes (permitir ventas con fechas de envío claras), buffers de stock (cantidad oculta para cubrir retrasos de sincronización) y actualizaciones atómicas (reducir stock en la misma operación que confirma el pedido).
Los casos límite son donde aparece el “stock misterioso”. Las devoluciones deben sumar stock solo después de inspección, no cuando se crea la etiqueta de devolución. Los artículos dañados deben moverse a un estado o ubicación separado para que no aparezcan vendibles. Los ajustes de stock necesitan una pista de auditoría (quién cambió qué y por qué), especialmente si múltiples canales actualizan inventario.
Los paquetes y kits añaden una regla clave: no decrementar un registro “paquete” si el paquete es solo un agrupamiento. Decrementa los artículos componentes. Un multipack de 3 debe reducir tres unidades del mismo SKU; un kit debe reducir una unidad de cada componente.
Ejemplo: un “Kit de inicio” incluye 1 botella y 2 filtros. Si tienes 10 botellas y 15 filtros, la disponibilidad del kit es 7 porque los filtros son el límite. Las matemáticas basadas en componentes mantienen informes, reembolsos y reabastecimiento consistentes.
En AppMaster, esto se mapea limpiamente a tablas de variantes en el Data Designer y lógica de reserva/decremento en el Business Process Editor, de modo que cada checkout sigue las mismas reglas.
Los paquetes son donde los catálogos suelen derivar en casos especiales. El enfoque más simple es modelar paquetes como ítems vendibles normales y luego adjuntar una lista clara de componentes.
Una estructura limpia es: Product (ítem vendible) más BundleLines. Cada BundleLine apunta a un SKU componente (o a un producto componente más una variante requerida) y guarda una cantidad. Los pedidos siguen mostrando “un artículo”, pero puedes expandirlo en partes cuando necesites coste, inventario y detalle de preparación.
La mayoría de configuraciones de paquete encajan en una de estas:
El precio es donde los equipos rompen informes accidentalmente. Decide desde el principio qué aparece en la línea del pedido y qué alimenta los informes de margen e inventario. Enfoques comunes: precio fijo de paquete, suma de partes o suma con descuento con reglas por componente (por ejemplo, “elige 3, el más barato al 50%”).
El inventario debe ser igual de estricto: un kit está disponible solo si cada componente requerido está disponible en la cantidad necesaria. Para informes, guarda dos vistas de la venta:
En AppMaster, esto encaja de forma natural: una tabla Bundle más filas BundleLine, con Business Processes que expanden componentes en el checkout y escriben la venta del paquete y el consumo de componentes en una sola transacción.
Una buena UI de opciones mantiene a la gente avanzando. Una mala UI les hace adivinar, chocar con errores y marcharse. La clave es guiar al comprador hacia una variante real y comprable temprano, mostrando claramente lo que cambian sus elecciones.
Un patrón fiable es mostrar las opciones (Talla, Color, Material) y luego calcular y mostrar solo las elecciones que siguen teniendo sentido.
En lugar de dejar que los clientes elijan cualquier combinación y fallar al Añadir al carrito, desactiva las combinaciones imposibles tan pronto como el usuario haga una elección. Por ejemplo, cuando alguien escoge Color = Black, las tallas que no existen en Black deben quedar deshabilitadas (no eliminadas), para que el cliente entienda qué no está disponible.
A medida que la selección cambia, actualiza las partes que más importan: precio (incluido precio en oferta y cualquier descuento de paquete), imágenes principales (coincidir con el color o estilo seleccionado), estado de stock (stock exacto de la variante, no stock genérico del producto), estimación de entrega (si varía por variante) y opcionalmente el SKU o “código de artículo” para soporte.
Mantén la interfaz serena. Muestra pocos grupos de opciones a la vez, evita desplegables enormes cuando swatches o botones funcionan mejor y deja claro cuál es la selección actual.
En administración, la gente necesita rapidez, no tarjetas bonitas. Una cuadrícula de variantes funciona bien: cada fila es un SKU, cada columna es una opción o una regla (precio, código de barras, peso, stock, activo/inactivo). Añade acciones masivas para tareas comunes como actualizar precios, alternar disponibilidad o asignar imágenes.
Si lo construyes en AppMaster, una configuración práctica es una rejilla vinculada a tu tabla Variant con filtros (valor de opción, estado activo, poco stock) y una acción de actualización masiva que valide reglas antes de guardar.
Un flujo de selección debe sentirse simple, pero necesita reglas estrictas bajo el capó. El objetivo es saber siempre qué SKU exacto está configurando el comprador y si puede comprarse ahora.
Carga algo más que el nombre del producto y las imágenes. Necesitas el conjunto completo de valores de opción (Talla, Color) y la lista de combinaciones válidas de variantes que existen como SKUs.
Un flujo fiable:
Un pequeño detalle de UI que evita frustración: desactiva los valores de opción imposibles tan pronto como se hagan elecciones anteriores. Si Size=M solo existe en Black, muestra otros colores como no disponibles una vez seleccionado M.
Para paquetes, “en stock” no es un único número. Depende de componentes. La regla habitual es:
bundle_available = mínimo entre componentes de floor(component_stock / component_qty_per_bundle)
Ejemplo: un “Kit de inicio” necesita 1 botella y 2 filtros. Si tienes 10 botellas y 9 filtros, la disponibilidad es min(floor(10/1)=10, floor(9/2)=4) = 4 kits.
Los mensajes de error deben ser concretos. Es preferible “Solo 4 kits disponibles (los filtros limitan este paquete)” a “Agotado”. En AppMaster, este tipo de comprobación es sencillo de expresar en un Business Process: calcula la variante coincidente primero, luego los límites del paquete y devuelve un estado claro para que la UI lo muestre.
Los catálogos fallan cuando modelas “todo lo que podría existir” en lugar de “lo que realmente vas a vender”. La forma más rápida de meterte en un callejón es generar todas las combinaciones posibles de opciones desde el inicio y luego intentar mantenerlo limpio conforme crece el catálogo.
Crear variantes que nunca se almacenarán es la trampa clásica. Si tienes 4 colores × 6 tallas × 3 materiales, son 72 variantes. Si solo 10 se venderán, las otras 62 filas generan desorden, invitan a errores y ralentizan informes.
El precio es otra fuente silenciosa de bugs. Los problemas empiezan cuando el mismo precio existe en múltiples sitios (producto, variante, tabla de precios, tabla de promociones) sin una fuente de verdad única. Una regla simple ayuda: guarda el precio base una vez y sólo guarda sobrescrituras donde realmente se necesiten (por ejemplo, una variante con precio distinto).
Los paquetes y kits fallan en inventario cuando decrementas tanto el paquete como sus componentes. Si vendes un “Kit de inicio” que incluye 1 botella y 2 filtros, restar 1 kit y además restar 1 botella y 2 filtros hace que el stock llegue a cero demasiado pronto. Mantén el paquete como ítem vendible, pero calcula disponibilidad y decrementos desde sus componentes.
Las herramientas de administración pueden causar daños si permiten datos inválidos. Agrega salvaguardas temprano:
Finalmente, planifica el cambio. Añadir una nueva opción después (como “Ancho” para zapatos) es una migración, no una casilla de verificación. Decide qué pasa con variantes existentes, cómo se establecen los valores por defecto y cómo los pedidos antiguos mantienen su SKU y snapshot de opciones.
Antes de publicar, haz una pasada sobre las cosas que fallan en la vida real: encontrar SKUs, actualizar stock y bloquear compras imposibles.
Asegúrate de que cada SKU vendible sea fácil de localizar. La búsqueda debe encontrarlo por nombre, código SKU, código de barras/GTIN y atributos clave (como talla o color). Si usas escaneo en almacén, prueba algunos escaneos físicos y confirma que apuntan al SKU exacto, no solo al producto padre.
Sé estricto sobre dónde ocurren los cambios de stock. Elige una fuente de la verdad (tu lógica de movimiento de inventario) y asegúrate de que cada evento la utilice: pedidos, cancelaciones, reembolsos, ajustes manuales y ensamblaje de paquetes. Si el stock puede editarse en dos pantallas o flujos, la deriva está garantizada.
Comprobaciones de lanzamiento que vale la pena ejecutar:
Si construyes en AppMaster, mantén las reglas de actualización de stock en un solo Business Process y llámalo desde cada ruta. Ese hábito único previene la mayoría de bugs de inventario.
Imagina una tienda de ropa que aún necesita un catálogo serio.
Vendes una camiseta con dos opciones: Talla (S, M, L) y Color (Black, White). Cada combinación comprable es su propia variante con su propio SKU, precio (si hace falta) e inventario.
En el esquema, guarda un Product para “Classic T-shirt”, dos Option (Size, Color) y varias Variant. Cada Variant guarda sus OptionValues seleccionados (por ejemplo: Size=M, Color=Black) y el SKU (por ejemplo: TSH-CL-M-BLK). El inventario se controla a nivel Variant, no Product.
En la UI, estrecha las opciones y evita callejones. Un patrón limpio es: mostrar todos los Colors primero y luego solo las Sizes que existen para el Color elegido (o al revés). Si “White + L” no existe, no permitas seleccionarla o muéstrala deshabilitada con una nota clara.
Ahora añade un paquete: “Gift Set” que incluye:
La disponibilidad del paquete está limitada por el componente más escaso. Si Sticker pack tiene stock 5, no puedes vender más de 5 paquetes aunque las camisetas estén sobradas. Si el paquete requiere una variante de camiseta específica (por ejemplo, Black M), entonces la disponibilidad del paquete es min(StickerPackStock, BlackMStock).
Pasos prácticos en AppMaster:
Si quieres prototipar esto de extremo a extremo rápidamente, AppMaster (appmaster.io) está pensado para construir apps completas con lógica de negocio real, que es exactamente de lo que dependen la selección de variantes y las reglas de inventario para paquetes.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
