# Orders, Order Items y Workflows en Drupal Commerce

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

Después de comprender productos, variaciones y precios, debemos estudiar otra de las piezas centrales de Drupal Commerce: **el ciclo de vida de un pedido**.

En Commerce, un pedido no aparece únicamente cuando el cliente termina el checkout.

El Order existe desde mucho antes.

De hecho, cuando el cliente añade un producto al carrito, Commerce puede crear un Order que todavía se encuentra en estado de borrador.

Ese mismo Order irá evolucionando durante el proceso comercial:

```plaintext
Carrito
   ↓
Checkout
   ↓
Pedido realizado
   ↓
Procesamiento
   ↓
Fulfillment
   ↓
Completado
```

La arquitectura gira principalmente alrededor de cuatro conceptos:

- Order
- Order Item
- Order Type
- Order Workflow

Comprenderlos correctamente nos permitirá diseñar procesos de compra mucho más claros antes de entrar en Checkout, Payments y Shipping.

---

## 1. Order: la transacción comercial

Un **Order** representa una transacción comercial.

Contiene información relacionada con la compra completa.

Por ejemplo:

```plaintext
Order #1001

Customer:
Daniel Example

Store:
Online Store

Items:
├── Laptop × 1
└── Mouse × 2

Subtotal:
1,100 EUR

Promotion:
-100 EUR

Tax:
+190 EUR

Shipping:
+10 EUR

Total:
1,200 EUR
```

Además de los productos, el Order puede contener información como:

- Customer
- Store
- Billing profile
- Order Items
- Adjustments
- Total
- Estado
- Fechas
- Checkout information
- Campos personalizados

Podemos pensar en el Order como el contenedor principal de la transacción.

---

## 2. El carrito también es un Order

Una de las ideas más importantes de Drupal Commerce es que el carrito no es una entidad completamente diferente del pedido.

Conceptualmente:

```plaintext
Usuario añade producto
        ↓
Se crea / reutiliza un Order
        ↓
Order marcado como Cart
        ↓
State = Draft
        ↓
Usuario continúa comprando
```

El mismo Order que funciona como carrito posteriormente puede convertirse en el pedido definitivo.

No necesitamos transformar una entidad llamada Cart en otra entidad llamada Order.

Es el mismo objeto comercial evolucionando.

```plaintext
ORDER

Draft
  │
  │ funciona como
  ▼
Cart

  ↓ Checkout

Placed Order
```

Esta arquitectura simplifica el sistema y permite que el carrito ya utilice muchas de las capacidades del Order:

- Order Items
- Prices
- Adjustments
- Promotions
- Taxes
- Customer information

---

## 3. Order ID frente a Order Number

Un carrito ya puede tener un identificador interno de Order.

Sin embargo, normalmente el número comercial del pedido se genera cuando el Order es colocado.

Conceptualmente:

```plaintext
Cart

Order ID: 384
Order Number: todavía no
State: Draft
```

Después:

```plaintext
Order placed

Order ID: 384
Order Number: 2026-001024
State: Fulfillment
```

El Order sigue siendo el mismo.

Lo que cambia es su estado dentro del proceso comercial y, entre otras cosas, pasa a tener un número de pedido.

---

## 4. Order Item: una línea del pedido

Los productos comprados no se almacenan directamente dentro del Order.

El Order contiene **Order Items**.

Por ejemplo:

```plaintext
Order #1001

Order Item #1
├── Product Variation: Laptop / 16 GB / 512 GB
├── Quantity: 1
├── Unit Price: 1,000 EUR
└── Total: 1,000 EUR

Order Item #2
├── Product Variation: Wireless Mouse / Black
├── Quantity: 2
├── Unit Price: 50 EUR
└── Total: 100 EUR
```

Cada Order Item representa una línea comercial concreta dentro del pedido.

---

## 5. La relación entre Variation y Order Item

Cuando el cliente añade una Product Variation al carrito:

```plaintext
Product
Laptop Pro

        ↓

Variation
16 GB / 512 GB

        ↓

Add to Cart

        ↓

Order Item

        ↓

Order
```

El Order Item mantiene una referencia hacia la entidad comprada.

Normalmente:

```plaintext
Order Item
     │
     └── Purchased Entity
             │
             └── Product Variation
```

Pero el Order Item almacena también información propia de esa compra.

---

## 6. Por qué necesitamos Order Items

Podríamos preguntarnos:

> ¿Por qué no referencia el Order directamente a las Product Variations?

Porque la compra necesita información que no pertenece al producto.

Por ejemplo:

```plaintext
Product Variation

SKU:
SHIRT-BLK-M

Current Price:
30 EUR
```

Pero dentro de un pedido:

```plaintext
Order Item

Purchased Entity:
SHIRT-BLK-M

Quantity:
3

Unit Price:
25 EUR

Customization:
"Drupal Camp 2026"
```

La Product Variation describe lo que podemos comprar.

El Order Item describe **cómo esa entidad fue comprada dentro de una transacción concreta**.

---

## 7. Order Items pueden tener campos

Los Order Items son entidades fieldable.

Esto significa que podemos añadir información específica de una compra.

Por ejemplo, vendemos una camiseta personalizada:

```plaintext
Product Variation

Black / Medium
SKU: TS-BLK-M
```

El cliente introduce:

```plaintext
Custom text:
"Drupal Camp 2026"
```

Podemos almacenar ese dato en el Order Item:

```plaintext
Order Item

Purchased Entity:
TS-BLK-M

Quantity:
1

Custom Text:
Drupal Camp 2026
```

Esto tiene mucho más sentido que guardar ese texto en la Product Variation.

La regla conceptual sigue siendo:

```plaintext
Información del producto
        ↓
Product

Información de la unidad comprable
        ↓
Variation

Información específica de esta compra
        ↓
Order Item

Información de toda la transacción
        ↓
Order
```

---

## 8. Order Item Type

Los Order Items pertenecen a un **Order Item Type**.

Este tipo define su estructura.

Por ejemplo:

```plaintext
Order Item Type
Physical Product

Fields:
├── Purchased Entity
├── Quantity
├── Unit Price
└── Total Price
```

Podríamos tener otro:

```plaintext
Order Item Type
Personalized Product

Fields:
├── Purchased Entity
├── Quantity
├── Unit Price
├── Custom Text
└── Uploaded Artwork
```

Esto permite adaptar la línea de pedido a diferentes modelos comerciales.

---

## 9. Product Variation Type y Order Item Type

El Product Variation Type determina qué Order Item Type se utilizará al comprar una Variation.

Por ejemplo:

```plaintext
Product Variation Type
Personalized T-Shirt
        │
        ▼
Order Item Type
Personalized Product
```

Cuando el cliente añade esa Variation:

```plaintext
Product Variation
       ↓
Order Item Type asociado
       ↓
Order Item
       ↓
Order
```

Esta relación permite que diferentes tipos de productos generen líneas de pedido con estructuras diferentes.

---

## 10. Order Type

Al igual que existen Product Types, también existen **Order Types**.

El Order Type permite configurar el comportamiento de una determinada clase de pedidos.

Entre otras cosas, un Order Type puede determinar:

- Order Workflow
- Checkout Flow
- Refresh behavior
- Cart behavior
- Number pattern
- Campos adicionales

Podríamos tener:

```plaintext
Order Types

├── Physical Products
└── Digital Products
```

porque ambos procesos comerciales son diferentes.

---

## 11. No necesitamos un Order Type por Product Type

Debemos evitar una relación automática como:

```plaintext
Product Type A
        ↓
Order Type A

Product Type B
        ↓
Order Type B

Product Type C
        ↓
Order Type C
```

No existe ninguna razón para crear esta estructura si todos los productos siguen el mismo proceso comercial.

La pregunta correcta es:

> ¿Estos pedidos necesitan comportamientos o ciclos de vida diferentes?

Por ejemplo:

```plaintext
T-Shirts
Shoes
Backpacks
        ↓
All physical goods
        ↓
Order Type:
Physical Order
```

Aunque existan varios Product Types, pueden participar en el mismo proceso de pedido.

---

## 12. Cuándo crear diferentes Order Types

Podría tener sentido cuando existen diferencias reales como:

- Diferentes workflows
- Diferentes checkout flows
- Diferentes necesidades de fulfillment
- Campos diferentes en el Order
- Diferentes procesos operativos

Por ejemplo:

```plaintext
Physical Order
        ↓
Payment
        ↓
Warehouse
        ↓
Shipping
        ↓
Completed
```

mientras:

```plaintext
Digital Order
        ↓
Payment
        ↓
Generate access
        ↓
Completed
```

Estos procesos justifican arquitecturas distintas.

---

## 13. Qué es un Workflow

Un **Workflow** describe cómo una entidad puede moverse entre diferentes estados.

Podemos imaginarlo como una máquina de estados.

```plaintext
State A
   ↓
Transition
   ↓
State B
```

En Commerce, el Order Workflow define el ciclo de vida permitido para un Order.

Por ejemplo:

```plaintext
Draft
   ↓
Place Order
   ↓
Fulfillment
   ↓
Fulfill
   ↓
Completed
```

El Workflow define dos conceptos fundamentales:

- States
- Transitions

---

## 14. State: dónde se encuentra el pedido

Un **State** describe la situación actual del Order dentro del proceso.

Ejemplos:

```plaintext
Draft
Validation
Processing
Fulfillment
Completed
Canceled
```

Podemos preguntar:

> ¿Dónde se encuentra actualmente este pedido dentro del proceso comercial?

La respuesta debería corresponder a un State.

---

## 15. Transition: cómo cambia el pedido

Una **Transition** representa una acción permitida para mover el pedido de un estado a otro.

Por ejemplo:

```plaintext
State:
Draft

Transition:
Place order

New State:
Fulfillment
```

O:

```plaintext
State:
Fulfillment

Transition:
Fulfill

New State:
Completed
```

Visualmente:

```plaintext
Draft
   │
   │ Place order
   ▼
Fulfillment
   │
   │ Fulfill
   ▼
Completed
```

Esto es diferente de permitir cambiar arbitrariamente el estado mediante un select.

El Workflow define explícitamente qué cambios son válidos.

---

## 16. Estados y transiciones no son lo mismo

Esta diferencia merece ser clara.

```plaintext
State
= situación actual

Transition
= acción que provoca el cambio
```

Por ejemplo:

```plaintext
Processing
= State

Ship order
= Transition

Shipped
= nuevo State
```

Nombrar correctamente ambos conceptos ayuda mucho cuando diseñamos workflows personalizados.

---

## 17. State Machine

Drupal Commerce utiliza el módulo **State Machine** para implementar estos workflows.

Conceptualmente:

```plaintext
Order
  ↓
State Machine
  ↓
Workflow
  ├── States
  └── Transitions
```

Esto permite definir qué estados existen y qué caminos están permitidos entre ellos.

La misma idea puede utilizarse en otros procesos diferentes de Orders.

---

## 18. El workflow más simple

Para un producto que no necesita fulfillment complejo podemos tener un workflow muy pequeño.

```plaintext
Draft
   │
   │ Place order
   ▼
Completed
```

También puede existir la posibilidad de cancelar:

```plaintext
Draft
   ├──────────────→ Canceled
   │
   │ Place order
   ▼
Completed
```

Este proceso puede ser suficiente para determinados productos digitales o servicios simples.

---

## 19. Fulfillment Workflow

Los productos físicos suelen necesitar un estado intermedio después de colocar el pedido.

Conceptualmente:

```plaintext
Draft
   ↓
Place order
   ↓
Fulfillment
   ↓
Fulfill
   ↓
Completed
```

El estado Fulfillment representa que el pedido ya fue colocado, pero todavía existe trabajo operativo pendiente.

Por ejemplo:

```plaintext
Order placed
     ↓
Warehouse
     ↓
Picking
     ↓
Packing
     ↓
Shipping
     ↓
Completed
```

Commerce no necesita representar necesariamente cada una de esas operaciones como estados separados.

Eso dependerá de los requisitos reales del negocio.

---

## 20. Workflow con Validation

En algunos procesos necesitamos validar el pedido antes de comenzar fulfillment.

Podemos tener:

```plaintext
Draft
   ↓
Place order
   ↓
Validation
   ↓
Validate
   ↓
Fulfillment
   ↓
Fulfill
   ↓
Completed
```

La validación podría representar procesos como:

- Revisión antifraude
- Confirmación del pago
- Verificación de disponibilidad
- Revisión manual
- Validación de datos comerciales

La semántica exacta debería corresponder a los procesos reales de la empresa.

---

## 21. Cancelación

Normalmente un workflow también necesita contemplar la cancelación.

Por ejemplo:

```plaintext
Draft
   ├──────────────→ Canceled
   │
   ▼
Validation
   ├──────────────→ Canceled
   │
   ▼
Fulfillment
   ├──────────────→ Canceled
   │
   ▼
Completed
```

Sin embargo, debemos definir claramente desde qué estados puede cancelarse un pedido.

Por ejemplo:

```plaintext
Draft
→ cancelable

Validation
→ cancelable

Fulfillment
→ maybe cancelable

Completed
→ normally no direct cancellation
```

Esto depende del modelo comercial.

---

## 22. Canceled no es lo mismo que Refunded

Esta distinción es especialmente importante.

Un Order puede ser:

```plaintext
Canceled
```

porque la transacción comercial no continuará.

Pero un pago puede ser:

```plaintext
Refunded
```

porque dinero previamente recibido fue devuelto.

No son el mismo concepto.

```plaintext
Order Workflow
        ↓
Canceled

Payment Workflow
        ↓
Refunded
```

Un pedido puede necesitar un reembolso como consecuencia de una cancelación, pero son procesos diferentes.

---

## 23. El Order Workflow no es el Payment Workflow

Otro error frecuente es mezclar el estado del pedido con el estado del pago.

Podemos tener:

```plaintext
Order
State:
Fulfillment
```

mientras:

```plaintext
Payment
State:
Completed
```

O:

```plaintext
Order
State:
Validation

Payment
State:
Authorization
```

El Order y el Payment tienen responsabilidades diferentes.

Conceptualmente:

```plaintext
Order Workflow
= ciclo de vida comercial / operativo

Payment Workflow
= ciclo de vida del dinero
```

Commerce mantiene estos procesos separados precisamente para evitar workflows excesivamente complejos.

---

## 24. El Checkout tampoco es el Order Workflow

También debemos diferenciar:

```plaintext
Checkout Flow
        ≠
Order Workflow
```

El Checkout Flow describe los pasos que sigue el cliente para proporcionar información y completar la compra.

Por ejemplo:

```plaintext
Login
  ↓
Customer information
  ↓
Shipping
  ↓
Payment
  ↓
Review
  ↓
Complete
```

El Order Workflow describe el estado operativo del pedido.

```plaintext
Draft
  ↓
Validation
  ↓
Fulfillment
  ↓
Completed
```

Podemos ver ambos procesos simultáneamente:

```plaintext
CHECKOUT                    ORDER

Cart                        Draft
  │                           │
Customer information          │
  │                           │
Shipping                      │
  │                           │
Payment                       │
  │                           │
Review                        │
  │                           │
Complete ────────────────→ Place order
                              │
                              ▼
                          Fulfillment
```

Esta separación es fundamental para comprender la arquitectura de Commerce.

---

## 25. Payment, Checkout, Order y Fulfillment son procesos diferentes

Podemos resumir:

```plaintext
Checkout Flow
= cómo el cliente completa la compra

Order Workflow
= cómo evoluciona la transacción

Payment Workflow
= cómo evoluciona el pago

Fulfillment
= cómo cumplimos la obligación
  de entregar lo comprado
```

Los cuatro procesos se relacionan, pero no debemos convertirlos artificialmente en un único workflow.

---

## 26. Diseñar workflows desde el negocio

No deberíamos comenzar preguntando:

> ¿Qué workflow de Commerce debo seleccionar?

Primero deberíamos describir el proceso real.

Por ejemplo:

```plaintext
Customer places order
        ↓
Finance verifies payment
        ↓
Warehouse confirms stock
        ↓
Warehouse prepares order
        ↓
Carrier collects package
        ↓
Order delivered
```

Después preguntamos:

> ¿Qué partes de este proceso necesitamos representar como estados del Order?

Podríamos decidir:

```plaintext
Draft
   ↓
Validation
   ↓
Processing
   ↓
Fulfillment
   ↓
Completed
```

Pero quizás no necesitemos tantos estados.

---

## 27. No convertir cada acción operativa en un State

Supongamos que nuestro almacén realiza:

```plaintext
Order received
    ↓
Print picking list
    ↓
Pick products
    ↓
Quality control
    ↓
Pack
    ↓
Print shipping label
    ↓
Carrier pickup
```

Eso no significa automáticamente que necesitemos:

```plaintext
Picking
Quality Control
Packing
Label Printed
Waiting Carrier
Shipped
```

como estados de Commerce.

Quizá todo ese proceso pueda representarse simplemente como:

```plaintext
Fulfillment
```

mientras el ERP o Warehouse Management System gestiona los detalles.

Debemos representar en Commerce solamente los estados que tengan significado para nuestro sistema.

---

## 28. Cuándo sí necesitamos un State adicional

Puede tener sentido introducir un nuevo estado cuando:

- Cambia quién es responsable del pedido
- Se necesita una acción manual
- Debemos impedir determinadas operaciones
- Una integración depende de ese estado
- El cliente necesita conocerlo
- Tiene significado comercial o legal

Por ejemplo:

```plaintext
Pending Approval
```

puede ser importante en un sistema B2B donde una orden debe ser aprobada antes de procesarse.

---

## 29. Ejemplo B2C sencillo

Una tienda online tradicional podría tener:

```plaintext
Draft
   ↓
Place Order
   ↓
Fulfillment
   ↓
Fulfill
   ↓
Completed
```

Proceso real:

```plaintext
Customer
   ↓
Cart
   ↓
Checkout
   ↓
Payment
   ↓
Order placed
   ↓
Warehouse
   ↓
Shipment
   ↓
Completed
```

El Payment puede tener su propio ciclo de vida independiente.

---

## 30. Ejemplo B2B

Supongamos ahora una empresa que vende maquinaria a distribuidores.

El proceso es:

```plaintext
Distributor creates order
        ↓
Sales representative reviews order
        ↓
Credit conditions verified
        ↓
Order approved
        ↓
ERP receives order
        ↓
Warehouse fulfills
        ↓
Completed
```

Podríamos diseñar:

```plaintext
Draft
   ↓
Place
   ↓
Review
   ↓
Approve
   ↓
Fulfillment
   ↓
Complete
```

También podríamos permitir:

```plaintext
Review
  ├── Approve
  └── Reject / Cancel
```

Este workflow refleja mucho mejor el negocio que intentar utilizar obligatoriamente un proceso B2C estándar.

---

## 31. Ejemplo digital

Supongamos que vendemos una licencia digital.

El proceso podría ser:

```plaintext
Cart
   ↓
Checkout
   ↓
Payment completed
   ↓
License generated
   ↓
Customer receives access
```

Quizás necesitemos solamente:

```plaintext
Draft
   ↓
Place
   ↓
Completed
```

El proceso de generación de la licencia puede ejecutarse automáticamente como consecuencia de una transición o evento.

No necesitamos introducir un complejo workflow de Shipping cuando no existe ningún envío físico.

---

## 32. Ejemplo de servicio

Supongamos que vendemos una consultoría.

Podríamos tener:

```plaintext
Draft
   ↓
Placed
   ↓
Scheduled
   ↓
Delivered
   ↓
Completed
```

Aquí el proceso de fulfillment no consiste en enviar un paquete.

Consiste en prestar el servicio.

Esto demuestra por qué debemos pensar en Commerce como un framework comercial y no exclusivamente como un sistema para vender productos físicos.

---

## 33. Custom Workflows

Los workflows proporcionados por Commerce cubren muchos escenarios comunes.

Pero podemos definir workflows personalizados cuando el negocio lo requiere.

Conceptualmente podríamos definir:

```plaintext
Draft
   ↓
Processing
   ↓
Fulfillment
   ↓
Completed
```

con transiciones:

```plaintext
place
process
fulfill
cancel
```

Los workflows personalizados se definen mediante configuración YAML proporcionada por un módulo.

Esto significa que no debemos diseñar procesos arbitrariamente complejos esperando configurarlos completamente desde la interfaz.

Cuando necesitamos workflows específicos, puede ser necesaria una pequeña capa de desarrollo personalizado.

---

## 34. Ejemplo conceptual de YAML

Sin entrar todavía en una implementación completa, un workflow personalizado puede tener una estructura conceptual similar a:

```plaintext
states:

  draft
  processing
  fulfillment
  completed
  canceled

transitions:

  place
    draft → processing

  process
    processing → fulfillment

  fulfill
    fulfillment → completed

  cancel
    draft / processing / fulfillment → canceled
```

Lo importante en esta etapa no es memorizar el YAML.

Lo importante es comprender que el Workflow contiene una definición explícita de:

```plaintext
States
+
Allowed Transitions
```

---

## 35. Las transiciones pueden provocar lógica adicional

Una Transition no tiene por qué significar únicamente cambiar un valor.

Otros componentes pueden reaccionar cuando ocurre.

Por ejemplo:

```plaintext
Transition:
Place Order

        ↓

Possible reactions:

├── Generate order number
├── Send email
├── Notify ERP
├── Create invoice
├── Reserve stock
└── Log commercial event
```

O:

```plaintext
Transition:
Complete Order

        ↓

Possible reactions:

├── Close fulfillment
├── Notify customer
├── Update CRM
└── Record analytics event
```

Commerce y Drupal permiten reaccionar programáticamente a estos eventos.

---

## 36. Las integraciones deberían respetar el workflow

Supongamos que debemos enviar pedidos al ERP.

Podríamos preguntarnos:

> ¿Cuándo debe enviarse el Order al ERP?

Posibles respuestas:

```plaintext
When order is placed
```

o:

```plaintext
When payment is confirmed
```

o:

```plaintext
When internal validation is completed
```

Esto puede vincularse a una Transition clara.

```plaintext
Draft
   ↓
Place
   ↓
Validation
   ↓
Approve
   ↓
Send to ERP
```

Esto es preferible a ejecutar integraciones basadas en condiciones ambiguas o en inspeccionar constantemente campos del Order.

---

## 37. Order Refresh

Mientras un Order continúa siendo un carrito, las condiciones comerciales pueden cambiar.

Por ejemplo:

```plaintext
Monday

Product price
100 EUR

Tuesday

Product price
90 EUR
```

El cliente añadió el producto el lunes pero vuelve el martes.

Commerce dispone de un proceso de **Order Refresh** que permite recalcular información del Order mientras todavía está en una fase editable.

Durante este proceso pueden actualizarse aspectos como:

- Unit Prices
- Availability
- Promotions
- Adjustments
- Otros cálculos comerciales

El Order Type permite configurar aspectos relacionados con este refresh.

---

## 38. Draft Order frente a pedido colocado

Existe una diferencia comercial importante entre:

```plaintext
Draft Order
```

y:

```plaintext
Placed Order
```

Durante Draft todavía tenemos una intención de compra.

```plaintext
Customer changes quantity
Customer removes products
Prices may refresh
Promotions may change
Availability may change
```

Una vez colocado el pedido, comenzamos a tratarlo como una transacción comercial.

```plaintext
Order Number
Placed Date
Commercial history
Operational processing
```

Esta frontera es importante cuando diseñamos integraciones, auditoría y pricing.

---

## 39. No modificar silenciosamente pedidos históricos

Supongamos:

```plaintext
Order #1001

Placed:
January 2026

Product:
100 EUR
```

Meses después el producto cuesta:

```plaintext
120 EUR
```

El Order histórico debe continuar reflejando lo que realmente ocurrió:

```plaintext
Order #1001

Unit Price:
100 EUR
```

Un pedido colocado no debería comportarse como un catálogo en tiempo real.

Representa una transacción histórica.

---

## 40. Order Workflow frente a Fulfillment real

Debemos evitar asumir que Commerce necesariamente gestionará todo el proceso físico.

Podemos tener:

```plaintext
Drupal Commerce
        ↓
Order placed
        ↓
ERP
        ↓
Warehouse
        ↓
Carrier
        ↓
Delivered
```

Commerce podría limitarse a mantener:

```plaintext
Fulfillment
        ↓
Completed
```

mientras los detalles operativos viven en otro sistema.

O Commerce podría manejar un proceso mucho más detallado.

La decisión depende de quién sea Source of Truth para fulfillment.

---

## 41. Preguntas para diseñar el Order Workflow

Antes de seleccionar o crear un workflow deberíamos responder:

### Creación

- ¿Cuándo se crea el Order?
- ¿Existe carrito?
- ¿Se permiten Orders administrativos?

### Placement

- ¿Cuándo consideramos que el pedido ha sido realizado?
- ¿Necesita pago previo?
- ¿Necesita aprobación?

### Processing

- ¿Existe revisión manual?
- ¿Existe validación antifraude?
- ¿Existe aprobación B2B?

### Fulfillment

- ¿Qué significa cumplir el pedido?
- ¿Producto físico, digital o servicio?
- ¿Quién gestiona el fulfillment?

### Cancellation

- ¿Desde qué estados se puede cancelar?
- ¿Quién puede hacerlo?
- ¿Qué ocurre con el pago?
- ¿Qué ocurre con el stock?

### Completion

- ¿Cuándo se considera completado?
- ¿Cuando se envía?
- ¿Cuando se entrega?
- ¿Cuando se presta el servicio?

### Integraciones

- ¿Cuándo enviamos el Order al ERP?
- ¿Cuándo reservamos stock?
- ¿Cuándo generamos una factura?
- ¿Qué sistema controla cada etapa?

---

## 42. Una matriz para decidir si necesitamos un estado

Podemos utilizar la siguiente guía.

```plaintext
¿Representa una situación comercial distinta?
        ↓
Posible State

¿Necesitamos controlar quién puede avanzar?
        ↓
Posible State + Transition

¿Una integración depende de este momento?
        ↓
Posible Transition

¿Es solamente una tarea interna menor?
        ↓
Quizá NO necesita un State

¿Otro sistema gestiona ese detalle?
        ↓
Quizá NO necesita un State
```

Esto ayuda a evitar workflows innecesariamente complicados.

---

## 43. Un modelo mental completo

Podemos visualizar todo el proceso así:

```plaintext
PRODUCT
   │
   ▼
PRODUCT VARIATION
   │
   │ Add to cart
   ▼
ORDER ITEM
   │
   ▼
ORDER
   │
   ▼
DRAFT / CART
   │
   │ Checkout
   ▼
PLACE ORDER
   │
   ▼
ORDER WORKFLOW
   │
   ├── Validation
   │
   ├── Processing
   │
   ├── Fulfillment
   │
   ├── Completed
   │
   └── Canceled

```

Mientras tanto existen procesos relacionados pero independientes:

```plaintext
ORDER
 │
 ├── Checkout Flow
 │
 ├── Payment Workflow
 │
 ├── Pricing / Adjustments
 │
 └── Shipping / Fulfillment
```

Commerce conecta estos procesos sin obligarnos a tratarlos como una única máquina de estados.

---

## 44. La regla de las cinco preguntas

Podemos resumir este artículo mediante cinco preguntas.

```plaintext
1. ¿Qué está comprando el cliente?
        ↓
Order Item

2. ¿Cuál es la transacción completa?
        ↓
Order

3. ¿Qué tipo de transacción es?
        ↓
Order Type

4. ¿En qué situación está actualmente?
        ↓
State

5. ¿Qué acción permite avanzar?
        ↓
Transition
```

Si podemos responder claramente estas cinco preguntas, estamos en buenas condiciones para diseñar el ciclo de vida del pedido.

---

## Conclusión

En Drupal Commerce, el Order es mucho más que el resultado final del checkout.

Es la entidad central que acompaña la transacción desde el carrito hasta su finalización.

Podemos resumir los conceptos principales así:

```plaintext
Order
= transacción comercial completa

Cart
= Order todavía en Draft

Order Item
= línea concreta de la compra

Order Item Type
= estructura de esa línea

Order Type
= configuración de una clase de Orders

State
= situación actual del Order

Transition
= acción permitida entre estados

Order Workflow
= ciclo de vida permitido del pedido
```

La idea más importante es mantener separados los diferentes procesos:

```plaintext
Checkout
        ↓
experiencia para completar la compra

Order Workflow
        ↓
ciclo de vida de la transacción

Payment Workflow
        ↓
ciclo de vida del dinero

Fulfillment
        ↓
cumplimiento de lo comprado
```

Diseñar correctamente estas responsabilidades evita workflows gigantescos y hace que Commerce sea mucho más fácil de extender e integrar.

En el siguiente artículo estudiaremos precisamente el siguiente proceso: **Checkout en Drupal Commerce**.

Veremos qué es un Checkout Flow, cómo se organiza en Steps y Panes, cómo recopila información del comprador y, sobre todo, cómo distinguir correctamente el checkout de los workflows del Order y del Payment.

##  Course navigation: Drupal Commerce

Chapter 6 of 11

- [ ← Anterior Precios en Drupal Commerce: Price, Adjustments, Promotions e Impuestos ](/es/precios-en-drupal-commerce-price-adjustments-promotions-e-impuestos)
- [ Siguiente → Checkout en Drupal Commerce: Flows, Steps y Panes ](/es/checkout-en-drupal-commerce-flows-steps-y-panes)

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