# Precios en Drupal Commerce: Price, Adjustments, Promotions e Impuestos

 Enviado por [danieluxury](/es/user/1 "Ver perfil del usuario.") el Vie, 25 Sep 2026 - 11:42

Después de modelar correctamente nuestro catálogo, necesitamos entender una de las partes más importantes de cualquier sistema de comercio electrónico: **cómo se calcula el precio que finalmente paga el cliente**.

A primera vista podría parecer sencillo:

```plaintext
Producto
   ↓
Precio
   ↓
Total
```

Pero en un sistema real pueden intervenir muchos factores:

- Precio base
- Tipo de cliente
- Store
- Moneda
- Cantidad
- Promociones
- Cupones
- Impuestos
- Shipping
- Fees

Por eso Drupal Commerce separa diferentes conceptos relacionados con pricing.

Comprender estas diferencias es fundamental antes de comenzar a configurar promociones, impuestos o reglas de precios.

---

## 1. El precio no es necesariamente un valor fijo

En el modelo más sencillo podemos tener:

```plaintext
Product Variation

SKU: SHIRT-BLACK-M
Price: 25.00 EUR
```

El producto cuesta 25 EUR y no existe ninguna otra regla.

Pero podemos encontrar escenarios más complejos:

```plaintext
Precio base
    ↓
Cliente B2B
    ↓
Descuento por volumen
    ↓
Promoción
    ↓
Impuestos
    ↓
Shipping
    ↓
Total final
```

Por tanto debemos distinguir claramente entre:

- El precio almacenado
- El precio resuelto
- El precio unitario del Order Item
- Los Adjustments
- El total del pedido

---

## 2. Price: precio de la Product Variation

Las Product Variations tienen un campo de precio.

Por ejemplo:

```plaintext
Product
Classic T-Shirt

Variation
Black / Medium

SKU
TS-BLK-M

Price
25.00 EUR
```

Este precio representa el valor comercial inicial de la entidad comprable.

Podemos pensar inicialmente:

```plaintext
Product Variation
        ↓
      Price
        ↓
    25.00 EUR
```

En una tienda sencilla este valor puede ser suficiente.

Pero Commerce permite que el precio utilizado durante la compra sea determinado dinámicamente.

---

## 3. Price es cantidad y moneda

Un precio no es simplemente un número.

Conceptualmente contiene al menos:

```plaintext
Number
+
Currency
```

Por ejemplo:

```plaintext
25.00 EUR

99.90 USD

120.00 CHF
```

Por este motivo no deberíamos tratar los precios como campos numéricos genéricos.

La moneda forma parte del significado del precio.

```plaintext
100 EUR ≠ 100 USD ≠ 100 CHF
```

---

## 4. List Price

Además del Price principal, una Product Variation puede disponer de un **List Price**.

Podemos utilizarlo conceptualmente para representar un precio de referencia.

Por ejemplo:

```plaintext
List price
100 EUR

Price
79 EUR
```

La presentación podría mostrar:

```plaintext
Antes: 100 EUR
Ahora: 79 EUR
```

Es importante entender que el List Price es principalmente información de presentación.

No debemos confundirlo con el sistema de promociones.

Una promoción representa una regla comercial aplicada durante el cálculo de la compra.

Por tanto:

```plaintext
List Price
= precio de referencia para mostrar

Promotion
= regla que modifica económicamente una compra
```

---

## 5. El precio almacenado no siempre es el precio utilizado

Drupal Commerce permite resolver dinámicamente el precio de una entidad comprable.

Esto significa que aunque tengamos:

```plaintext
Variation Price
100 EUR
```

el precio utilizado para un determinado cliente podría ser:

```plaintext
Customer A
→ 100 EUR

Customer B
→ 90 EUR

Distributor
→ 75 EUR
```

O podría depender de otras condiciones:

```plaintext
Store
Customer
Quantity
Date
Currency
Price list
```

Aquí aparece un concepto fundamental de Commerce:

**Price Resolver.**

---

## 6. Price Resolver

Un Price Resolver determina qué precio debe utilizarse para una entidad comprable dentro de un contexto determinado.

En el caso sencillo:

```plaintext
Product Variation
        ↓
Price Resolver
        ↓
Price field
        ↓
25 EUR
```

El resolver por defecto puede simplemente utilizar el precio almacenado en la Variation.

Pero podemos introducir otras fuentes.

Por ejemplo:

```plaintext
Product Variation
        ↓
Price Resolver
        ↓
Price List
        ↓
Customer Group
        ↓
Resolved Price
```

Supongamos:

```plaintext
SKU: PRODUCT-001

Retail price:
100 EUR

Distributor price:
80 EUR
```

Dependiendo del comprador:

```plaintext
Regular Customer
        ↓
100 EUR

Distributor
        ↓
80 EUR
```

No necesitamos necesariamente modificar el Product Variation cada vez.

El precio puede resolverse dinámicamente.

---

## 7. Price Resolver frente a Promotion

Esta diferencia es especialmente importante.

Supongamos que un distribuidor tiene permanentemente un precio especial.

```plaintext
Retail
100 EUR

Distributor
80 EUR
```

Podríamos interpretar 80 EUR como el precio real de ese producto para ese cliente.

Esto encaja conceptualmente con:

```plaintext
Price Resolver
        ↓
Resolved Price
80 EUR
```

En cambio, supongamos que durante una semana tenemos:

```plaintext
Summer Sale

20 % discount
```

Ahora podríamos tener:

```plaintext
Resolved Price
100 EUR
    ↓
Promotion
-20 EUR
    ↓
Final contribution
80 EUR
```

Podemos utilizar esta distinción:

```plaintext
¿Cuál es el precio real
para este cliente/contexto?
        ↓
Price Resolver

¿Qué descuento o recargo
aplicamos sobre la compra?
        ↓
Adjustment
```

---

## 8. Order Item Unit Price

Cuando añadimos una Product Variation al carrito, Commerce crea un Order Item.

Ese Order Item tiene un **Unit Price**.

Por ejemplo:

```plaintext
Product Variation
SKU: TS-BLK-M

Resolved Price:
25 EUR
        ↓
Add to cart
        ↓
Order Item

Quantity: 2
Unit Price: 25 EUR
```

Podemos pensar:

```plaintext
Product Variation Price
        ↓
Price Resolution
        ↓
Order Item Unit Price
```

El Order Item representa la compra concreta, por lo que su precio participa posteriormente en el cálculo del pedido.

---

## 9. Quantity y Total Price

El siguiente cálculo es sencillo:

```plaintext
Unit Price × Quantity
        ↓
Order Item Total
```

Por ejemplo:

```plaintext
Unit Price
25 EUR

Quantity
3

Subtotal
75 EUR
```

Sin embargo, todavía pueden aparecer promociones, impuestos y otros Adjustments.

---

## 10. Adjustments

Los **Adjustments** son uno de los conceptos centrales del sistema de pricing de Drupal Commerce.

Un Adjustment representa una modificación económica aplicada a un Order o a un Order Item.

Por ejemplo:

```plaintext
Promotion
-10 EUR

Tax
+19 EUR

Shipping
+8 EUR

Fee
+2 EUR
```

Podemos visualizarlo así:

```plaintext
Subtotal
100 EUR

Promotion
-10 EUR

Tax
+17.10 EUR

Shipping
+8 EUR
────────────────
Total
115.10 EUR
```

Los Adjustments permiten mantener separados los diferentes conceptos que contribuyen al total.

---

## 11. Un Adjustment puede ser positivo o negativo

Podemos pensar en dos grandes grupos.

### Adjustment negativo

Reduce el total.

```plaintext
Promotion
-20 EUR
```

### Adjustment positivo

Incrementa el total.

```plaintext
Tax
+19 EUR

Shipping
+8 EUR

Special fee
+3 EUR
```

Conceptualmente:

```plaintext
Base amount
    +
Adjustments
    =
Final amount
```

---

## 12. Tipos habituales de Adjustment

Commerce puede trabajar con diferentes tipos de Adjustment.

Entre los más importantes encontramos:

```plaintext
Promotion
Tax
Fee
Custom
```

Otros módulos pueden introducir tipos adicionales.

Por ejemplo, Commerce Shipping puede incorporar:

```plaintext
Shipping
Shipping Promotion
```

Esto crea una arquitectura extensible.

```plaintext
Order / Order Item
       │
       ├── Promotion adjustment
       ├── Tax adjustment
       ├── Shipping adjustment
       └── Custom adjustment
```

---

## 13. Order Item Adjustments frente a Order Adjustments

Los Adjustments pueden aplicarse en diferentes niveles.

Podemos tener un descuento específico sobre un producto:

```plaintext
Order Item

Laptop
1000 EUR

Promotion
-100 EUR

Adjusted item
900 EUR
```

O un descuento sobre el pedido completo:

```plaintext
Order

Subtotal
1000 EUR

Order promotion
-100 EUR

Adjusted subtotal
900 EUR
```

La diferencia puede ser importante para:

- Presentación
- Impuestos
- Reembolsos
- Reporting
- Integraciones

---

## 14. Promotions

Una **Promotion** define una estrategia comercial de descuento.

Podemos tener promociones como:

```plaintext
10 % off all products

20 EUR off orders over 200 EUR

15 % off laptops

Free shipping over 100 EUR

10 % discount for distributors
```

Conceptualmente una promoción responde a tres preguntas:

```plaintext
¿Cuándo se aplica?
        ↓
Conditions

¿Qué beneficio obtiene?
        ↓
Offer

¿Durante qué periodo existe?
        ↓
Availability
```

---

## 15. Conditions y Offers

Supongamos:

> Aplicar 10 % de descuento cuando el pedido supere 100 EUR.

Podemos separar:

```plaintext
Condition

Order total ≥ 100 EUR

Offer

10 % discount
```

Otro ejemplo:

> Aplicar 20 % de descuento a productos de la categoría Shoes.

```plaintext
Condition

Product category = Shoes

Offer

20 % discount
```

Esta separación permite construir promociones reutilizables y comprensibles.

---

## 16. Promoción sobre el pedido

Una promoción puede afectar al Order completo.

Por ejemplo:

```plaintext
Subtotal
200 EUR

Promotion
10 % off order

Adjustment
-20 EUR

Result
180 EUR
```

Este tipo de promoción tiene sentido cuando el beneficio depende del pedido global.

---

## 17. Promoción sobre productos

También podemos aplicar promociones solamente a determinados Order Items.

Por ejemplo:

```plaintext
Order

Laptop
1000 EUR
Promotion -100 EUR

Mouse
50 EUR
No promotion
```

El descuento está asociado al producto correspondiente y no al Order completo.

---

## 18. Coupons

Un Coupon permite que el cliente active una promoción mediante un código.

Por ejemplo:

```plaintext
Promotion
Summer Sale

Coupon
SUMMER2026
```

El cliente introduce:

```plaintext
SUMMER2026
```

y, si se cumplen las condiciones, se aplica la promoción correspondiente.

Es importante separar los conceptos:

```plaintext
Promotion
= regla comercial

Coupon
= código que puede activar
  una promoción
```

No todas las promociones necesitan Coupons.

Por ejemplo:

```plaintext
All orders over 100 EUR
→ Free shipping
```

puede aplicarse automáticamente.

---

## 19. Promotions no deberían reemplazar todas las reglas de pricing

Puede resultar tentador representar cualquier diferencia de precio mediante descuentos.

Por ejemplo:

```plaintext
Retail customer
100 EUR

Distributor
20 % promotion
→ 80 EUR
```

Esto puede ser apropiado en determinados negocios.

Pero si 80 EUR es realmente el precio contractual permanente para distribuidores, quizá sea más correcto modelarlo como pricing contextual.

```plaintext
Retail Price List
100 EUR

Distributor Price List
80 EUR
```

La pregunta debe ser:

> ¿Estamos cambiando el precio base para este contexto o estamos aplicando una promoción comercial?

Son conceptos relacionados, pero diferentes.

---

## 20. Impuestos como Adjustments

Los impuestos también participan en el sistema de Adjustments.

Supongamos:

```plaintext
Price
100 EUR

VAT
19 %

Tax adjustment
+19 EUR

Total
119 EUR
```

Conceptualmente:

```plaintext
Tax rule
    ↓
Tax calculation
    ↓
Tax Adjustment
    ↓
Order / Order Item
```

Esto permite identificar cuánto del total corresponde a impuestos.

---

## 21. Tax Type

Drupal Commerce organiza la configuración fiscal alrededor de **Tax Types**.

Podemos tener, por ejemplo:

```plaintext
Tax Type
European VAT

Rates
├── Standard
├── Reduced
└── Zero
```

La implementación concreta dependerá del país y de los requisitos fiscales del negocio.

Antes de configurarlos necesitamos tener claro:

- En qué países se vende
- Desde dónde vende la empresa
- Qué productos tienen tasas diferentes
- Qué clientes pueden estar exentos
- Si los precios se muestran con o sin impuestos

---

## 22. Impuestos incluidos y no incluidos

Existen dos formas conceptuales frecuentes de presentar impuestos.

### Precio sin impuestos incluidos

```plaintext
Product
100 EUR

VAT
+19 EUR

Total
119 EUR
```

### Precio con impuestos incluidos

```plaintext
Displayed price
119 EUR

Included VAT
19 EUR
```

En ambos casos necesitamos conocer el componente fiscal, aunque la presentación y el cálculo sean diferentes.

Esta decisión debe definirse durante el Discovery del negocio y no cuando estamos construyendo la página del producto.

---

## 23. Diferentes productos pueden tener tasas diferentes

No todos los productos tienen necesariamente la misma tasa fiscal.

Por ejemplo:

```plaintext
Physical Product
→ Standard VAT

Book
→ Reduced VAT

Exempt service
→ Zero / exempt rate
```

Esto significa que el sistema necesita saber qué tratamiento fiscal corresponde a cada producto o variación.

Esta información puede formar parte del modelado de la Product Variation cuando el negocio lo requiera.

---

## 24. Precio visible frente a precio final del pedido

Una distinción especialmente importante es que el precio mostrado en la página de producto no siempre puede representar exactamente el total final.

En una página podemos conocer:

```plaintext
Product
Variation
Customer
Store
Quantity
```

Pero todavía podemos desconocer:

```plaintext
Shipping address
Billing address
Shipping method
Coupon
Complete order contents
```

Por tanto algunos cálculos solamente pueden determinarse correctamente cuando existe suficiente contexto dentro del Order.

Podemos pensar:

```plaintext
Product page
        ↓
Estimated / calculated price

Cart
        ↓
More context

Checkout
        ↓
Full commercial context

Order
        ↓
Final calculated totals
```

---

## 25. Calculated Price

Commerce puede mostrar un precio calculado que tenga en cuenta el proceso de resolución y determinados Adjustments.

Conceptualmente:

```plaintext
Stored Price
        ↓
Price Resolution
        ↓
Applicable Adjustments
        ↓
Calculated Price
```

Esto resulta útil para mostrar al cliente un precio más cercano al que realmente pagará.

Sin embargo, debemos recordar que determinados datos solamente estarán disponibles cuando el comprador avance en el proceso de compra.

---

## 26. Order Processors

Hasta ahora hemos visto que un Order puede recibir:

- Promotions
- Taxes
- Fees
- Otros Adjustments

Commerce utiliza un proceso de actualización del Order para recalcular su información comercial.

Conceptualmente:

```plaintext
Order
  ↓
Refresh
  ↓
Order Processors
  ├── Pricing
  ├── Promotions
  ├── Taxes
  └── Other business logic
  ↓
Updated Order
```

Los Order Processors permiten que diferentes componentes participen en la actualización del pedido sin concentrar toda la lógica en un único lugar.

---

## 27. Por qué Commerce recalcula el pedido

Supongamos que el cliente añade un producto al carrito:

```plaintext
Monday

Product
100 EUR
```

y regresa posteriormente cuando:

```plaintext
Tuesday

Product
90 EUR
```

O una promoción:

```plaintext
20 % weekend discount
```

ha expirado.

Commerce necesita decidir si la información del carrito todavía representa las condiciones comerciales actuales.

Por eso el Order puede pasar por procesos de refresh donde se vuelven a resolver precios y aplicar reglas.

Esta arquitectura es especialmente importante en tiendas con:

- Precios dinámicos
- Promociones frecuentes
- Price Lists
- Pricing B2B
- Integraciones ERP

---

## 28. El precio histórico del pedido

Una vez que un pedido representa una transacción comercial real, necesitamos conservar correctamente cuánto pagó el cliente.

No podemos simplemente consultar siempre el precio actual del Product Variation.

Por ejemplo:

```plaintext
January

Variation Price
100 EUR

Order #1001
Unit Price
100 EUR
```

Meses después:

```plaintext
September

Variation Price
120 EUR
```

El pedido histórico continúa representando:

```plaintext
Order #1001

Purchased price
100 EUR
```

Esta separación entre catálogo actual y transacción histórica es fundamental para reporting, facturación y atención al cliente.

---

## 29. Ejemplo completo de cálculo

Supongamos la siguiente compra:

```plaintext
Laptop
Unit Price
1000 EUR

Quantity
1

Mouse
Unit Price
50 EUR

Quantity
2
```

Subtotal:

```plaintext
Laptop
1000 EUR

Mouse
2 × 50 EUR
100 EUR
──────────
Subtotal
1100 EUR
```

Existe una promoción:

```plaintext
10 % discount on Laptop

Adjustment
-100 EUR
```

Nuevo subtotal efectivo:

```plaintext
1000 EUR
```

Posteriormente aplicamos impuestos, de forma simplificada para este ejemplo:

```plaintext
VAT
+190 EUR
```

Y shipping:

```plaintext
Shipping
+10 EUR
```

Podemos obtener:

```plaintext
Products
1100 EUR

Promotion
-100 EUR

Tax
+190 EUR

Shipping
+10 EUR
────────────────
Order Total
1200 EUR
```

La ventaja de utilizar Adjustments es que podemos identificar claramente cómo se formó el total.

---

## 30. Ejemplo B2B

Supongamos ahora que tenemos precios diferentes según el cliente.

```plaintext
SKU
TOOL-001

Retail Price
100 EUR

Distributor Price
75 EUR
```

Un distribuidor inicia sesión.

El proceso conceptual podría ser:

```plaintext
Product Variation
        ↓
Price Resolver
        ↓
Customer = Distributor
        ↓
Price List
        ↓
Resolved Price
75 EUR
        ↓
Order Item Unit Price
75 EUR
```

Posteriormente podría existir además una promoción:

```plaintext
Buy 10+
Additional 5 % discount
```

Entonces:

```plaintext
Resolved Unit Price
75 EUR

Quantity
10

Subtotal
750 EUR

Promotion
-37.50 EUR

Taxes
...

Total
...
```

Esta arquitectura separa correctamente:

```plaintext
Contractual / contextual price
        ↓
Price Resolver

Temporary commercial incentive
        ↓
Promotion Adjustment
```

---

## 31. Ejemplo multimoneda

También podemos tener diferentes precios dependiendo de la Store o moneda.

```plaintext
Product Variation
SKU: PRODUCT-001

Germany
→ 100 EUR

Switzerland
→ 110 CHF

United States
→ 115 USD
```

El precio utilizado puede depender del contexto comercial.

```plaintext
Store
+
Currency
+
Purchasable Entity
        ↓
Price Resolution
        ↓
Resolved Price
```

Esto es diferente de simplemente convertir visualmente 100 EUR a otra moneda.

En muchos negocios cada mercado tiene su propia estrategia de precios.

---

## 32. Price Lists

Cuando el negocio necesita múltiples precios por producto podemos introducir el concepto de **Price Lists**.

Por ejemplo:

```plaintext
Retail Price List

SKU-001 → 100 EUR
SKU-002 → 200 EUR

Distributor Price List

SKU-001 → 80 EUR
SKU-002 → 160 EUR
```

También pueden existir precios relacionados con:

```plaintext
Store
Customer
Role
Date
Quantity
```

Este tipo de modelo es especialmente habitual en B2B.

Commerce dispone de módulos contribuidos, como Commerce Pricelist, para implementar escenarios de este tipo.

---

## 33. Quantity Pricing

Otro requisito habitual es cambiar el precio dependiendo de la cantidad.

Por ejemplo:

```plaintext
1 - 9 units
10 EUR / unit

10 - 49 units
9 EUR / unit

50+ units
8 EUR / unit
```

Tenemos que decidir conceptualmente si esto representa:

```plaintext
Different unit price
        ↓
Price resolution
```

o:

```plaintext
Base price
+
Volume discount
        ↓
Promotion / Adjustment
```

Ambos modelos pueden producir un resultado parecido para el cliente, pero representan conceptos comerciales diferentes.

La elección debería reflejar cómo entiende el negocio sus precios.

---

## 34. Fees

No todos los Adjustments son descuentos o impuestos.

También podemos tener recargos.

Por ejemplo:

```plaintext
Handling Fee
+5 EUR

Small Order Fee
+10 EUR

Special Packaging
+8 EUR
```

Estos conceptos pueden representarse mediante Adjustments positivos.

De esta forma permanecen separados del precio del producto.

---

## 35. Shipping y pricing

Shipping también termina influyendo en el total de la compra.

Por ejemplo:

```plaintext
Products
100 EUR

Shipping
+8 EUR

Tax
+20 EUR

Total
128 EUR
```

Sin embargo, Shipping merece su propio modelo.

El coste puede depender de:

- Dirección
- Zona
- Peso
- Dimensiones
- Transportista
- Método seleccionado
- Valor del pedido

Por eso estudiaremos Shipping separadamente más adelante.

---

## 36. El orden del cálculo importa

Cuando existen varias reglas comerciales necesitamos comprender sobre qué valor se calcula cada una.

Por ejemplo:

```plaintext
Base price
100 EUR

Promotion
-20 %

Tax
+19 %
```

¿Calculamos el impuesto sobre:

```plaintext
100 EUR
```

o sobre:

```plaintext
80 EUR?
```

La respuesta depende de las reglas fiscales y comerciales aplicables.

Lo mismo puede ocurrir con múltiples promociones.

```plaintext
Promotion A
-10 %

Promotion B
-10 EUR
```

El orden y las condiciones pueden modificar el resultado.

Por eso debemos recopilar estas reglas claramente durante el Discovery.

---

## 37. Evitar lógica de precios en campos arbitrarios

Supongamos que añadimos a Product:

```plaintext
field_discount
field_special_price
field_wholesale_price
field_sale_price
field_vip_price
```

Inicialmente puede parecer una solución sencilla.

Pero rápidamente podemos terminar con:

```plaintext
Regular Price
Sale Price
VIP Price
Distributor Price
German Price
Swiss Price
Summer Price
Quantity Price
...
```

Antes de añadir un nuevo field debemos preguntarnos:

> ¿Estamos almacenando un dato del producto o intentando implementar una regla comercial?

Si estamos implementando reglas comerciales, probablemente debemos estudiar:

- Price Resolvers
- Price Lists
- Promotions
- Adjustments

en lugar de continuar añadiendo campos.

---

## 38. Separar los conceptos comerciales

Podemos utilizar esta matriz mental:

```plaintext
Precio normal de la Variation
        ↓
Price

Precio dependiendo del contexto
        ↓
Price Resolver

Precio de referencia visual
        ↓
List Price

Descuento comercial
        ↓
Promotion Adjustment

Impuesto
        ↓
Tax Adjustment

Recargo
        ↓
Fee Adjustment

Costo de entrega
        ↓
Shipping Adjustment
```

Esta separación hace que el sistema sea mucho más fácil de comprender y mantener.

---

## 39. Preguntas para el Discovery de pricing

Antes de configurar precios deberíamos poder responder:

### Precio base

- ¿Cada Variation tiene un precio propio?
- ¿De dónde procede ese precio?
- ¿Drupal es Source of Truth?
- ¿El precio proviene del ERP?

### Clientes

- ¿Existen precios diferentes por cliente?
- ¿Existen precios B2B?
- ¿Existen grupos de clientes?

### Mercados

- ¿Existen precios diferentes por país?
- ¿Existen diferentes monedas?
- ¿Cada Store tiene sus propios precios?

### Cantidades

- ¿Existen precios por volumen?
- ¿Son precios reales diferentes o descuentos?

### Promociones

- ¿Qué promociones existen?
- ¿A qué productos se aplican?
- ¿Se aplican automáticamente?
- ¿Necesitan Coupon?
- ¿Pueden combinarse?

### Impuestos

- ¿Qué Tax Types necesitamos?
- ¿Qué tasas existen?
- ¿Los precios incluyen impuestos?
- ¿Existen clientes exentos?

### Recargos

- ¿Existen fees adicionales?
- ¿Cuándo se aplican?

---

## 40. Un modelo mental completo

Podemos visualizar el pricing de Commerce de esta forma:

```plaintext
PRODUCT VARIATION
       │
       ▼
Stored Price
       │
       ▼
Price Resolver
       │
       ▼
Resolved Price
       │
       ▼
ORDER ITEM
       │
       ├── Quantity
       │
       ├── Promotion Adjustments
       │
       └── Tax Adjustments
       │
       ▼
Adjusted Item Total
       │
       ▼
ORDER
       │
       ├── Order Promotions
       ├── Taxes
       ├── Shipping
       ├── Fees
       └── Other Adjustments
       │
       ▼
ORDER TOTAL
```

No todos los proyectos utilizarán todas estas capas.

Una tienda sencilla puede necesitar solamente:

```plaintext
Variation Price
        ↓
Order Item
        ↓
Order Total
```

Mientras que un proyecto B2B internacional podría necesitar:

```plaintext
Variation
   ↓
Store
   ↓
Customer group
   ↓
Price List
   ↓
Quantity tier
   ↓
Resolved Price
   ↓
Promotion
   ↓
Tax
   ↓
Shipping
   ↓
Final Total
```

La arquitectura debe ser tan sencilla como permita el negocio, pero suficientemente flexible para representar sus reglas reales.

---

## 41. Una regla práctica para tomar decisiones

Podemos utilizar cuatro preguntas fundamentales:

```plaintext
1. ¿Cuál es el precio de esta Variation?
        ↓
Price

2. ¿Cuál es el precio correcto
   para este contexto?
        ↓
Price Resolver

3. ¿Qué descuentos o recargos
   se aplican a esta compra?
        ↓
Adjustments

4. ¿Cuánto termina pagando
   el cliente?
        ↓
Order Total
```

Estas preguntas ayudan a separar conceptos que inicialmente pueden parecer iguales.

---

## Conclusión

El sistema de precios de Drupal Commerce no se limita a almacenar un número dentro de una Product Variation.

Commerce separa diferentes responsabilidades:

```plaintext
Price
= precio de la entidad comprable

List Price
= precio de referencia visual

Price Resolver
= determina el precio apropiado
  para un contexto

Order Item Unit Price
= precio utilizado en la línea
  concreta del pedido

Adjustment
= modificación económica

Promotion
= descuento comercial

Tax
= obligación fiscal

Order Total
= resultado final de la transacción
```

Esta separación permite construir desde tiendas muy sencillas hasta sistemas complejos con múltiples Stores, monedas, grupos de clientes, Price Lists, promociones e impuestos.

La idea principal es evitar pensar:

> ¿Qué campo necesito para guardar este nuevo precio?

y comenzar preguntando:

> ¿Este dato representa un precio, una regla de pricing o un Adjustment sobre la transacción?

Responder correctamente esa pregunta puede evitar gran parte de la complejidad futura de un proyecto Commerce.

En el siguiente artículo profundizaremos en otro elemento fundamental del proceso comercial: **Orders, Order Items y Workflows**, entendiendo el ciclo de vida de un carrito desde que se crea hasta que el pedido es completado, cancelado o reembolsado.

##  Course navigation: Drupal Commerce

Chapter 5 of 11

- [ ← Anterior Modelar el catálogo en Drupal Commerce: Products, Variations, Attributes, Fields y Taxonomies ](/es/modelar-el-catalogo-en-drupal-commerce-products-variations-attributes-fields-y-taxonomies)
- [ Siguiente → Orders, Order Items y Workflows en Drupal Commerce ](/es/orders-order-items-y-workflows-en-drupal-commerce)

 [↑ Course index](/es/node/43)