Modelar el catálogo en Drupal Commerce: Products, Variations, Attributes, Fields y Taxonomies

Una de las decisiones más importantes en un proyecto Drupal Commerce es cómo representar correctamente el catálogo.

Antes de crear Product Types, campos o taxonomías debemos responder una pregunta fundamental:

¿Cómo está estructurada realmente la información comercial que queremos vender?

Un catálogo bien modelado facilita la administración, los filtros, la búsqueda, el mantenimiento, las integraciones y futuras ampliaciones del sitio.

Un catálogo mal modelado puede funcionar inicialmente, pero suele terminar acumulando campos duplicados, Product Types innecesarios, variaciones difíciles de mantener y reglas especiales para resolver problemas que en realidad nacieron en el modelo de datos.

En este artículo aprenderemos a decidir cuándo utilizar:

• Product Type
• Product
• Product Variation Type
• Product Variation
• Product Attribute
• Field
• Taxonomy

El objetivo no es memorizar configuraciones, sino desarrollar un criterio que podamos reutilizar en diferentes proyectos Commerce.

1. Empezar por el catálogo real

No deberíamos comenzar preguntándonos:

¿Cuántos Product Types debemos crear?

Primero necesitamos observar el catálogo del cliente.

Supongamos que una empresa vende:

Catálogo

├── Camisetas
├── Sudaderas
├── Zapatos
├── Mochilas
└── Accesorios

Sería tentador crear inmediatamente:

Product Types

├── Camiseta
├── Sudadera
├── Zapato
├── Mochila
└── Accesorio

Pero esta decisión podría ser incorrecta.

Es posible que todos esos productos tengan exactamente la misma estructura:

Title
Description
Brand
Category
Images
Variations

En ese caso podríamos utilizar un único Product Type:

Product Type
Product

y representar las categorías mediante Taxonomy:

Product Category

├── Clothing
│   ├── T-Shirts
│   └── Sweatshirts
│
├── Shoes
├── Backpacks
└── Accessories

La categoría comercial de un producto y su estructura técnica son conceptos diferentes.

2. Product Type no significa categoría

Este es uno de los errores conceptuales más fáciles de cometer.

Un Product Type define principalmente la estructura y comportamiento de un tipo de Product.

Una categoría clasifica productos.

Por ejemplo:

Categorías

Electronics
├── Computers
├── Phones
├── Tablets
└── Accessories

No necesariamente necesitamos cuatro Product Types.

Si todos comparten una estructura compatible, podemos tener:

Product Type
Electronic Product

Taxonomy
Product Category
├── Computers
├── Phones
├── Tablets
└── Accessories

En cambio, podríamos justificar Product Types diferentes cuando los productos necesitan estructuras claramente diferentes.

Por ejemplo:

Physical Book

Fields:
├── Author
├── Publisher
├── ISBN
├── Number of pages
└── Description


Online Course

Fields:
├── Instructor
├── Duration
├── Difficulty level
├── Course curriculum
└── Description

Aquí existe una diferencia estructural real.

3. Cuándo crear un Product Type diferente

Podemos utilizar varias preguntas para tomar esta decisión.

¿Los productos necesitan:

• Campos significativamente diferentes?
• Variation Types diferentes?
• Interfaces administrativas diferentes?
• Displays significativamente diferentes?
• Comportamientos comerciales diferentes?
• Procesos específicos asociados al tipo de producto?

Si la respuesta es afirmativa para varias de estas preguntas, probablemente estamos ante Product Types diferentes.

Por ejemplo:

Product Type: Physical Product
├── Description
├── Brand
├── Category
└── Documentation


Product Type: Software
├── Description
├── System requirements
├── Supported platforms
└── Documentation

La regla práctica puede expresarse así:

¿Solo cambia la clasificación?
        ↓
Probablemente Taxonomy


¿Cambia la estructura del producto?
        ↓
Probablemente Product Type

4. Product frente a Product Variation

Una vez definido el Product Type debemos separar correctamente el producto conceptual de aquello que realmente se vende.

Por ejemplo:

Product

Classic T-Shirt

puede tener:

Variations

├── Black / S
├── Black / M
├── Black / L
├── White / S
├── White / M
└── White / L

El Product representa:

Classic T-Shirt

La Variation representa:

Classic T-Shirt
Black
Medium
SKU: TS-BLK-M
Price: 24.90 EUR

Una forma sencilla de recordarlo es:

Product
= qué producto es


Variation
= cuál versión concreta compramos

5. Decidir dónde colocar un campo

Una de las preguntas más frecuentes durante el modelado es:

¿Este campo debería estar en el Product o en la Product Variation?

Existe una pregunta muy útil para resolverlo:

¿Este valor es común para todas las variaciones o puede cambiar entre ellas?

Supongamos este producto:

Product
Running Shoe X100

Variations
├── Black / 42
├── Black / 43
├── Blue / 42
└── Blue / 43

Podríamos almacenar en Product:

Title
Description
Brand
Product family
Technical documentation
Category

Y en Product Variation:

SKU
Price
Color
Size
Weight
Variation image

Podemos resumir:

¿Es común a todas las variaciones?
        ↓
Product


¿Puede cambiar según lo que compramos?
        ↓
Product Variation

6. Las imágenes son un buen ejemplo

Las imágenes muestran por qué no existe una regla absoluta sobre dónde debe vivir un campo.

Supongamos que todas las variaciones utilizan las mismas fotografías.

Product
Running Shoe X100

Images:
├── front.jpg
├── side.jpg
└── sole.jpg

En ese caso parece lógico almacenar las imágenes en el Product.

Pero si tenemos:

Variation
Black
   ↓
black-front.jpg
black-side.jpg


Variation
Blue
   ↓
blue-front.jpg
blue-side.jpg

entonces las imágenes están asociadas a la Variation.

La pregunta no es:

¿Dónde suelen almacenarse las imágenes en Commerce?

Sino:

¿Qué entidad describe realmente esta imagen?

7. Product Variation Type

Las Product Variations también tienen su propia estructura.

Esta estructura se define mediante un Product Variation Type.

Por ejemplo:

Product Type
Clothing
        │
        ▼
Variation Type
Clothing Variation

Fields / attributes:
├── Color
├── Size
├── SKU
├── Price
└── Weight

Otro Product Type podría necesitar:

Product Type
Laptop
        │
        ▼
Variation Type
Laptop Configuration

Fields / attributes:
├── RAM
├── Storage
├── Keyboard
├── SKU
├── Price
└── Weight

La estructura de la unidad comprable es diferente y por eso puede resultar apropiado utilizar Variation Types diferentes.

8. Cuándo crear un Variation Type diferente

Podemos plantearnos:

• ¿Las variaciones tienen atributos diferentes?
• ¿Necesitan campos comerciales diferentes?
• ¿Necesitan un Order Item Type diferente?
• ¿Representan unidades comprables estructuralmente distintas?

Por ejemplo:

Clothing Variation

Attributes:
├── Color
└── Size


Book Variation

Attribute:
└── Format


Laptop Variation

Attributes:
├── RAM
├── Storage
└── Keyboard layout

En este caso tiene sentido separar los Variation Types.

Pero si dos familias de productos utilizan exactamente la misma estructura de variaciones, crear dos Variation Types diferentes puede añadir complejidad sin aportar valor.

9. Product Attributes

Un Product Attribute representa una propiedad utilizada para diferenciar y seleccionar Product Variations.

El ejemplo clásico es una camiseta.

Attribute: Color

├── Black
├── White
└── Blue


Attribute: Size

├── S
├── M
├── L
└── XL

Estas opciones pueden producir variaciones:

Black / S
Black / M
Black / L
White / S
White / M
White / L
Blue / S
Blue / M
Blue / L

Cuando el usuario selecciona:

Color: Blue
Size: M

Commerce puede determinar qué Product Variation representa esa combinación.

10. Attribute no significa propiedad

Es importante no interpretar la palabra Attribute de Drupal Commerce como cualquier atributo descriptivo del producto.

Un portátil puede tener características como:

Manufacturer: Lenovo
Processor: Intel Core Ultra
Screen technology: OLED
Wi-Fi: Wi-Fi 7

Esto no significa que debamos crear Product Attributes para todas ellas.

Si el cliente no selecciona entre esas propiedades para elegir una Variation, pueden ser simplemente fields.

En cambio:

RAM
├── 16 GB
└── 32 GB

Storage
├── 512 GB
├── 1 TB
└── 2 TB

pueden funcionar perfectamente como Attributes si representan opciones que determinan la variación comprable.

Podemos utilizar esta pregunta:

¿El usuario selecciona este valor para determinar qué Variation está comprando?

Si la respuesta es sí, probablemente estamos ante un Product Attribute.

11. Attribute frente a Field

Comparemos ambos conceptos.

Product Attribute

Participa en la selección entre Product Variations.

Size
Color
Storage
RAM
Format

Field

Almacena información acerca del Product o Variation.

Manufacturer
Technical description
EAN
Weight
Manual
Release date

Un mismo concepto puede ser Attribute en una tienda y field en otra.

Por ejemplo, Color.

En una tienda de camisetas:

Color
        ↓
Attribute

El comprador selecciona:
Black / White / Blue

Pero en una tienda de maquinaria podría existir:

Machine color:
Industrial Gray

sin que el comprador pueda escogerlo.

Entonces puede ser simplemente un field descriptivo.

El modelo depende del negocio, no del nombre del dato.

12. Attributes frente a opciones personalizadas

Existe otra distinción muy importante.

Supongamos que vendemos una camiseta personalizada.

El cliente selecciona:

Color: Black
Size: M
Custom text: "Drupal Camp 2026"

Color y Size pueden determinar una Variation:

Black / M
SKU: SHIRT-BLK-M

Pero no queremos generar previamente una Variation para cada posible texto.

SHIRT-BLK-M-DANIEL
SHIRT-BLK-M-MARIA
SHIRT-BLK-M-DRUPAL
...

El texto es información propia de la compra.

Conceptualmente:

Opción conocida previamente
que identifica lo que vendemos
        ↓
Attribute / Variation


Dato proporcionado específicamente
para esta compra
        ↓
Order Item

Esta diferencia se vuelve especialmente importante cuando trabajamos con productos personalizados.

13. Fields frente a Taxonomy

Otra decisión habitual en Drupal es determinar cuándo utilizar un field simple y cuándo utilizar una Taxonomy.

Supongamos que queremos almacenar la marca.

Podríamos crear:

Text field:

Brand = "Lenovo"

Pero también podríamos crear:

Taxonomy: Brand

├── Apple
├── Dell
├── HP
├── Lenovo
└── Microsoft

La segunda opción puede ser mucho más útil si necesitamos:

• Reutilizar valores
• Evitar diferentes formas de escribir el mismo valor
• Filtrar productos
• Crear páginas de marca
• Añadir metadata a una marca
• Relacionar otros contenidos con esa marca

14. Cuándo utilizar Taxonomy

Taxonomy suele ser una buena solución cuando tenemos un conjunto reutilizable y administrable de conceptos.

Por ejemplo:

Product Category
Brand
Product Family
Collection
Application
Industry

Una Taxonomy también puede tener estructura jerárquica.

Product Category

Electronics
├── Computers
│   ├── Laptops
│   └── Desktops
│
├── Tablets
└── Smartphones

Esto puede resultar especialmente útil para navegación y filtros.

15. Cuándo no utilizar Taxonomy

Taxonomy no debería convertirse automáticamente en el lugar donde almacenamos cualquier lista de valores.

Por ejemplo:

Weight: 1.42 kg
Width: 32 cm
Warranty: 24 months
Release year: 2026

Probablemente estos datos deberían utilizar tipos de campo apropiados.

Crear vocabularios como:

Weight
├── 1.4 kg
├── 1.42 kg
├── 1.45 kg
└── 1.5 kg

normalmente no tendría sentido.

Podemos preguntarnos:

¿Estamos representando un concepto reutilizable o simplemente almacenando un valor?

Si estamos almacenando un valor, probablemente necesitamos un field.

16. Taxonomy frente a Product Attribute

Estos dos conceptos también pueden parecer similares.

Supongamos que tenemos colores.

Podríamos utilizar Color para clasificar productos:

Color classification

├── Black
├── Blue
└── White

O utilizarlo como Attribute para seleccionar una Variation:

Product
Classic T-Shirt

Select color:
[ Black ▼ ]

Select size:
[ M ▼ ]

La pregunta nuevamente es funcional:

¿Estamos clasificando el producto o seleccionando la unidad concreta que queremos comprar?

Clasificar / navegar / filtrar
        ↓
Taxonomy


Seleccionar una Variation
        ↓
Product Attribute

Dependiendo del proyecto, puede existir relación entre ambos conceptos, pero no debemos asumir que son equivalentes.

17. Un ejemplo más completo: tienda de laptops

Supongamos que queremos construir una tienda de laptops.

Tenemos estos productos:

ThinkPad X1 Carbon
ThinkPad T14
MacBook Air
MacBook Pro
Dell XPS 13

Podríamos comenzar con:

Product Type:
Laptop

Campos del Product:

Title
Description
Brand
Product family
Processor family
Screen size
Technical specifications
Documentation
General images
Category

Variation Type:

Laptop Configuration

Attributes:

RAM

├── 16 GB
├── 24 GB
└── 32 GB


Storage

├── 512 GB
├── 1 TB
└── 2 TB

Campos de Variation:

SKU
Price
Weight
EAN
Specific image
Availability data

Taxonomies:

Brand

├── Apple
├── Dell
└── Lenovo


Product Category

Electronics
└── Computers
    └── Laptops

Podríamos terminar con:

Product
ThinkPad X1 Carbon

Brand
Lenovo

Category
Laptops

Variations
├── 16 GB / 512 GB
│   ├── SKU: X1-16-512
│   └── Price: 1,399 EUR
│
├── 16 GB / 1 TB
│   ├── SKU: X1-16-1TB
│   └── Price: 1,549 EUR
│
└── 32 GB / 1 TB
    ├── SKU: X1-32-1TB
    └── Price: 1,749 EUR

Este modelo separa claramente:

• Identidad del producto
• Clasificación
• Información descriptiva
• Opciones comerciales
• Unidad vendible

18. Segundo ejemplo: tienda de libros

Supongamos ahora una librería.

El producto es:

Clean Architecture
Robert C. Martin

Podríamos tener:

Product Type
Book

Fields:

Author
Description
Publisher
Publication date
Language
Category
Cover

Variation Type:

Book Format

Attribute:

Format

├── Hardcover
├── Paperback
└── eBook

Variations:

Hardcover
├── SKU: BOOK-100-HC
├── Price: 39 EUR
└── ISBN: ...


Paperback
├── SKU: BOOK-100-PB
├── Price: 29 EUR
└── ISBN: ...


eBook
├── SKU: BOOK-100-EB
└── Price: 19 EUR

En este modelo, Hardcover, Paperback y eBook no son necesariamente tres Products independientes.

Pueden ser tres formas comprables del mismo Product.

19. Tercer ejemplo: producto sin opciones

No todos los productos necesitan múltiples variaciones.

Supongamos:

Product
Drupal Commerce Handbook

Solo existe una edición.

Podemos tener:

Product

Drupal Commerce Handbook

└── Variation
    ├── SKU: DCH-001
    └── Price: 39 EUR

No necesitamos inventar Attributes.

La Variation sigue siendo necesaria porque representa la entidad comprable, pero puede existir una sola.

1 Product
    ↓
1 Variation

Una buena arquitectura no necesita ser compleja cuando el negocio no lo es.

20. Cuidado con la explosión de variaciones

Los Attributes pueden generar muchas combinaciones.

Supongamos:

10 colores
×
8 tamaños
×
5 materiales

Tenemos potencialmente:

10 × 8 × 5 = 400 variaciones

Si añadimos:

4 acabados

pasamos a:

1.600 combinaciones

Esto debería hacernos preguntar si todas esas opciones representan realmente unidades comerciales diferentes.

Una propiedad debería convertirse en parte de una Variation cuando exista una razón comercial para ello, por ejemplo:

• SKU diferente
• Precio diferente
• Stock independiente
• Peso diferente
• Disponibilidad independiente
• Integración independiente con ERP

Si una opción es simplemente una personalización del pedido, quizás no debería multiplicar el número de Variations.

21. El SKU como pista de modelado

Una pregunta particularmente útil durante el Discovery es:

¿Esta combinación tiene un SKU propio en el negocio?

Por ejemplo:

Black / Small
SKU: TS-BLK-S

Black / Medium
SKU: TS-BLK-M

Blue / Small
SKU: TS-BLU-S

Esto es una indicación fuerte de que estamos ante Product Variations diferentes.

Sin embargo, el SKU no debería ser nuestra única regla.

Podemos encontrar negocios donde la identificación comercial provenga de un ERP u otro sistema externo y necesitemos considerar también inventario, pricing y fulfillment.

22. Pensar también en el ERP o PIM

En proyectos reales, el catálogo puede no originarse en Drupal Commerce.

Podemos tener:

PIM
 ↓
Product information
 ↓
Drupal Commerce


ERP
 ↓
SKU
Price
Stock
 ↓
Drupal Commerce

En ese caso nuestro modelo debería intentar representar correctamente la estructura del sistema que actúa como Source of Truth.

Por ejemplo:

PIM Product
       ↓
Commerce Product


ERP Article / SKU
       ↓
Commerce Product Variation

Si el ERP diferencia dos artículos mediante SKU independientes, puede ser una señal importante para nuestro modelo de Variations.

Diseñar Commerce sin comprender estas relaciones puede generar integraciones innecesariamente complejas.

23. Diseñar pensando en búsqueda y filtros

El modelo de catálogo también afecta directamente a la experiencia del usuario.

Supongamos que necesitamos filtros:

Brand
Category
Price
Color
Size
Material
Availability

Debemos saber dónde vive cada dato.

Brand
    → Product taxonomy

Category
    → Product taxonomy

Price
    → Variation

Color
    → Variation attribute

Size
    → Variation attribute

Material
    → Product field / taxonomy / attribute
      dependiendo del modelo

Availability
    → Variation / inventory system

Esta decisión posteriormente tendrá consecuencias sobre Search API, Views, Facets y la forma en que agregamos información procedente de múltiples Variations.

Por eso la arquitectura del catálogo debe diseñarse antes de construir los filtros.

24. Diseñar pensando en el editor

Una arquitectura técnicamente correcta también debe ser fácil de administrar.

Supongamos que un editor necesita crear 500 productos.

Debemos preguntarnos:

• ¿Cuántos campos deberá completar?
• ¿Qué campos son obligatorios?
• ¿Qué valores pueden reutilizarse?
• ¿Cómo creará las variaciones?
• ¿Quién mantiene los Attributes?
• ¿Quién mantiene las Taxonomies?
• ¿Los productos se crean manualmente o se importan?

Un modelo muy elegante desde el punto de vista técnico puede ser un problema si requiere un proceso editorial innecesariamente complicado.

El modelo debe funcionar tanto para el comprador como para quien administra el catálogo.

25. Diseñar pensando en traducciones

En proyectos multilingües debemos identificar qué información necesita traducción.

Por ejemplo:

Product

Title
Description
Technical content
        ↓
Translatable

Mientras que:

SKU
Price
EAN
Weight
        ↓
Normalmente no dependen del idioma

Los términos utilizados para clasificación también pueden necesitar traducción:

Category

DE: Werkzeuge
EN: Tools
ES: Herramientas

Este análisis es especialmente importante cuando Commerce se utiliza en varios países o idiomas.

26. Una matriz para decidir dónde vive cada dato

Podemos utilizar una matriz conceptual sencilla.

¿Describe el producto en general?
        ↓
Product field


¿Clasifica productos?
        ↓
Taxonomy


¿Diferencia unidades comprables?
        ↓
Product Attribute / Variation


¿Es información propia de la unidad comprable?
        ↓
Variation field


¿Es proporcionado por el comprador para esta compra?
        ↓
Order Item field

Podemos aplicarla a algunos ejemplos:

Descripción
→ Product


Marca
→ Taxonomy / Product


Categoría
→ Taxonomy / Product


Color seleccionable
→ Product Attribute / Variation


SKU
→ Variation


Precio
→ Variation


Peso específico
→ Variation


Manual técnico común
→ Product


Texto para grabado
→ Order Item


Mensaje de regalo
→ Order Item

27. Evitar duplicar información

Un buen modelo debería intentar mantener cada dato en un único lugar lógico.

Por ejemplo, si Brand pertenece al Product:

Product
Brand: Lenovo

Variations
├── 16 GB / 512 GB
├── 16 GB / 1 TB
└── 32 GB / 1 TB

no necesitamos repetir:

Variation 1
Brand: Lenovo

Variation 2
Brand: Lenovo

Variation 3
Brand: Lenovo

La duplicación dificulta:

• Edición
• Importación
• Sincronización
• Validación
• Mantenimiento

La información debería vivir en el nivel más alto donde continúe siendo verdadera.

Si un valor es común a todas las Variations, normalmente pertenece al Product.

28. No modelar pensando solamente en la página

Otro error frecuente es diseñar las entidades pensando únicamente en cómo queremos mostrar una página.

Por ejemplo:

Necesito mostrar estos datos juntos, por tanto deben estar en la misma entidad.

No necesariamente.

Drupal puede presentar información procedente de diferentes entidades.

Una página de producto puede combinar:

Product
├── Title
├── Description
├── Brand
└── Category

Current Variation
├── Price
├── SKU
├── Image
└── Availability

Related content
├── Documentation
├── Reviews
└── Related products

El modelo debe representar correctamente el dominio.

La capa de presentación puede posteriormente combinar esos datos.

29. Un proceso práctico para diseñar el catálogo

Antes de configurar Commerce podemos seguir este proceso.

Paso 1: listar las familias de productos

Laptops
Phones
Accessories
Software

Paso 2: listar la información necesaria

Title
Brand
Description
Category
RAM
Storage
Color
SKU
Price
Weight

Paso 3: identificar qué información es común

Product

Title
Brand
Description
Category

Paso 4: identificar qué cambia entre unidades vendibles

Variation

RAM
Storage
Color
SKU
Price
Weight

Paso 5: identificar las opciones que selecciona el comprador

Attributes

RAM
Storage
Color

Paso 6: identificar clasificaciones reutilizables

Taxonomies

Brand
Category

Paso 7: decidir Product Types y Variation Types

Solamente ahora decidimos cuántos tipos necesitamos.

30. Checklist de modelado del catálogo

Antes de empezar la configuración deberíamos poder responder:

Products

• ¿Qué representa un Product?
• ¿Qué información es común a todas sus Variations?
• ¿Cuántos Product Types necesitamos realmente?

Variations

• ¿Qué constituye una unidad vendible?
• ¿Qué provoca que necesitemos una Variation diferente?
• ¿Las Variations tienen SKU independiente?
• ¿Tienen precio independiente?
• ¿Tienen stock independiente?

Attributes

• ¿Qué opciones selecciona el comprador?
• ¿Qué opciones determinan una Variation?
• ¿Todas las combinaciones existen realmente?

Fields

• ¿El dato pertenece al Product o a la Variation?
• ¿Cuál es el tipo de campo apropiado?
• ¿Necesita traducción?

Taxonomies

• ¿Qué conceptos reutilizamos?
• ¿Necesitamos jerarquías?
• ¿Necesitamos utilizarlos para navegación o filtros?

Integraciones

• ¿Existe PIM?
• ¿Existe ERP?
• ¿Dónde se originan productos y SKUs?
• ¿Qué sistema es Source of Truth para cada dato?

31. La regla de las cinco preguntas

Podemos resumir gran parte del modelado del catálogo utilizando cinco preguntas.

1. ¿Qué producto presentamos?
        ↓
Product


2. ¿Qué unidad concreta vendemos?
        ↓
Product Variation


3. ¿Qué selecciona el usuario
   para determinar esa unidad?
        ↓
Product Attribute


4. ¿Cómo clasificamos el producto?
        ↓
Taxonomy


5. ¿Qué información simplemente
   describe una entidad?
        ↓
Field

Estas cinco preguntas resuelven una gran parte de las decisiones iniciales de arquitectura.

Conclusión

Modelar correctamente el catálogo es una de las habilidades más importantes al trabajar con Drupal Commerce.

El objetivo no es crear tantas estructuras como sea posible, sino encontrar el modelo más sencillo que represente correctamente el negocio.

Podemos resumir las responsabilidades principales así:

Product Type
= estructura de una familia de productos


Product
= producto conceptual presentado al usuario


Variation Type
= estructura de las unidades comprables


Product Variation
= unidad concreta que puede comprarse


Product Attribute
= opción que permite seleccionar una Variation


Taxonomy
= clasificación reutilizable


Field
= dato estructurado de una entidad

Y podemos utilizar una regla adicional:

No crees una nueva estructura porque los datos se llamen diferente. Créala cuando el negocio necesite una estructura o comportamiento diferente.

Un catálogo bien diseñado simplificará prácticamente todo lo que construiremos después: búsqueda, filtros, precios, inventario, importaciones, integraciones, checkout y administración.

Una vez definido correctamente qué vendemos y cómo representamos nuestros productos, podemos avanzar hacia otra de las partes centrales de Drupal Commerce: precios y ajustes.

En el siguiente artículo estudiaremos cómo Commerce representa el precio, dónde se almacena, cómo distinguir precio base y precio final, y cómo intervienen promociones, impuestos y otros adjustments en el cálculo de un pedido.