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:
Carrito
↓
Checkout
↓
Pedido realizado
↓
Procesamiento
↓
Fulfillment
↓
CompletadoLa 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:
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 EURAdemá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:
Usuario añade producto
↓
Se crea / reutiliza un Order
↓
Order marcado como Cart
↓
State = Draft
↓
Usuario continúa comprandoEl 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.
ORDER
Draft
│
│ funciona como
▼
Cart
↓ Checkout
Placed OrderEsta 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:
Cart
Order ID: 384
Order Number: todavía no
State: DraftDespués:
Order placed
Order ID: 384
Order Number: 2026-001024
State: FulfillmentEl 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:
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 EURCada 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:
Product
Laptop Pro
↓
Variation
16 GB / 512 GB
↓
Add to Cart
↓
Order Item
↓
OrderEl Order Item mantiene una referencia hacia la entidad comprada.
Normalmente:
Order Item
│
└── Purchased Entity
│
└── Product VariationPero 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:
Product Variation
SKU:
SHIRT-BLK-M
Current Price:
30 EURPero dentro de un pedido:
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:
Product Variation
Black / Medium
SKU: TS-BLK-MEl cliente introduce:
Custom text:
"Drupal Camp 2026"Podemos almacenar ese dato en el Order Item:
Order Item
Purchased Entity:
TS-BLK-M
Quantity:
1
Custom Text:
Drupal Camp 2026Esto tiene mucho más sentido que guardar ese texto en la Product Variation.
La regla conceptual sigue siendo:
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
↓
Order8. Order Item Type
Los Order Items pertenecen a un Order Item Type.
Este tipo define su estructura.
Por ejemplo:
Order Item Type
Physical Product
Fields:
├── Purchased Entity
├── Quantity
├── Unit Price
└── Total PricePodríamos tener otro:
Order Item Type
Personalized Product
Fields:
├── Purchased Entity
├── Quantity
├── Unit Price
├── Custom Text
└── Uploaded ArtworkEsto 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:
Product Variation Type
Personalized T-Shirt
│
▼
Order Item Type
Personalized ProductCuando el cliente añade esa Variation:
Product Variation
↓
Order Item Type asociado
↓
Order Item
↓
OrderEsta 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:
Order Types
├── Physical Products
└── Digital Productsporque ambos procesos comerciales son diferentes.
11. No necesitamos un Order Type por Product Type
Debemos evitar una relación automática como:
Product Type A
↓
Order Type A
Product Type B
↓
Order Type B
Product Type C
↓
Order Type CNo 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:
T-Shirts
Shoes
Backpacks
↓
All physical goods
↓
Order Type:
Physical OrderAunque 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:
Physical Order
↓
Payment
↓
Warehouse
↓
Shipping
↓
Completedmientras:
Digital Order
↓
Payment
↓
Generate access
↓
CompletedEstos 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.
State A
↓
Transition
↓
State BEn Commerce, el Order Workflow define el ciclo de vida permitido para un Order.
Por ejemplo:
Draft
↓
Place Order
↓
Fulfillment
↓
Fulfill
↓
CompletedEl 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:
Draft
Validation
Processing
Fulfillment
Completed
CanceledPodemos 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:
State:
Draft
Transition:
Place order
New State:
FulfillmentO:
State:
Fulfillment
Transition:
Fulfill
New State:
CompletedVisualmente:
Draft
│
│ Place order
▼
Fulfillment
│
│ Fulfill
▼
CompletedEsto 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.
State
= situación actual
Transition
= acción que provoca el cambioPor ejemplo:
Processing
= State
Ship order
= Transition
Shipped
= nuevo StateNombrar 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:
Order
↓
State Machine
↓
Workflow
├── States
└── TransitionsEsto 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.
Draft
│
│ Place order
▼
CompletedTambién puede existir la posibilidad de cancelar:
Draft
├──────────────→ Canceled
│
│ Place order
▼
CompletedEste 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:
Draft
↓
Place order
↓
Fulfillment
↓
Fulfill
↓
CompletedEl estado Fulfillment representa que el pedido ya fue colocado, pero todavía existe trabajo operativo pendiente.
Por ejemplo:
Order placed
↓
Warehouse
↓
Picking
↓
Packing
↓
Shipping
↓
CompletedCommerce 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:
Draft
↓
Place order
↓
Validation
↓
Validate
↓
Fulfillment
↓
Fulfill
↓
CompletedLa 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:
Draft
├──────────────→ Canceled
│
▼
Validation
├──────────────→ Canceled
│
▼
Fulfillment
├──────────────→ Canceled
│
▼
CompletedSin embargo, debemos definir claramente desde qué estados puede cancelarse un pedido.
Por ejemplo:
Draft
→ cancelable
Validation
→ cancelable
Fulfillment
→ maybe cancelable
Completed
→ normally no direct cancellationEsto depende del modelo comercial.
22. Canceled no es lo mismo que Refunded
Esta distinción es especialmente importante.
Un Order puede ser:
Canceledporque la transacción comercial no continuará.
Pero un pago puede ser:
Refundedporque dinero previamente recibido fue devuelto.
No son el mismo concepto.
Order Workflow
↓
Canceled
Payment Workflow
↓
RefundedUn 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:
Order
State:
Fulfillmentmientras:
Payment
State:
CompletedO:
Order
State:
Validation
Payment
State:
AuthorizationEl Order y el Payment tienen responsabilidades diferentes.
Conceptualmente:
Order Workflow
= ciclo de vida comercial / operativo
Payment Workflow
= ciclo de vida del dineroCommerce mantiene estos procesos separados precisamente para evitar workflows excesivamente complejos.
24. El Checkout tampoco es el Order Workflow
También debemos diferenciar:
Checkout Flow
≠
Order WorkflowEl Checkout Flow describe los pasos que sigue el cliente para proporcionar información y completar la compra.
Por ejemplo:
Login
↓
Customer information
↓
Shipping
↓
Payment
↓
Review
↓
CompleteEl Order Workflow describe el estado operativo del pedido.
Draft
↓
Validation
↓
Fulfillment
↓
CompletedPodemos ver ambos procesos simultáneamente:
CHECKOUT ORDER
Cart Draft
│ │
Customer information │
│ │
Shipping │
│ │
Payment │
│ │
Review │
│ │
Complete ────────────────→ Place order
│
▼
FulfillmentEsta separación es fundamental para comprender la arquitectura de Commerce.
25. Payment, Checkout, Order y Fulfillment son procesos diferentes
Podemos resumir:
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 compradoLos 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:
Customer places order
↓
Finance verifies payment
↓
Warehouse confirms stock
↓
Warehouse prepares order
↓
Carrier collects package
↓
Order deliveredDespués preguntamos:
¿Qué partes de este proceso necesitamos representar como estados del Order?
Podríamos decidir:
Draft
↓
Validation
↓
Processing
↓
Fulfillment
↓
CompletedPero quizás no necesitemos tantos estados.
27. No convertir cada acción operativa en un State
Supongamos que nuestro almacén realiza:
Order received
↓
Print picking list
↓
Pick products
↓
Quality control
↓
Pack
↓
Print shipping label
↓
Carrier pickupEso no significa automáticamente que necesitemos:
Picking
Quality Control
Packing
Label Printed
Waiting Carrier
Shippedcomo estados de Commerce.
Quizá todo ese proceso pueda representarse simplemente como:
Fulfillmentmientras 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:
Pending Approvalpuede 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:
Draft
↓
Place Order
↓
Fulfillment
↓
Fulfill
↓
CompletedProceso real:
Customer
↓
Cart
↓
Checkout
↓
Payment
↓
Order placed
↓
Warehouse
↓
Shipment
↓
CompletedEl Payment puede tener su propio ciclo de vida independiente.
30. Ejemplo B2B
Supongamos ahora una empresa que vende maquinaria a distribuidores.
El proceso es:
Distributor creates order
↓
Sales representative reviews order
↓
Credit conditions verified
↓
Order approved
↓
ERP receives order
↓
Warehouse fulfills
↓
CompletedPodríamos diseñar:
Draft
↓
Place
↓
Review
↓
Approve
↓
Fulfillment
↓
CompleteTambién podríamos permitir:
Review
├── Approve
└── Reject / CancelEste 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:
Cart
↓
Checkout
↓
Payment completed
↓
License generated
↓
Customer receives accessQuizás necesitemos solamente:
Draft
↓
Place
↓
CompletedEl 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:
Draft
↓
Placed
↓
Scheduled
↓
Delivered
↓
CompletedAquí 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:
Draft
↓
Processing
↓
Fulfillment
↓
Completedcon transiciones:
place
process
fulfill
cancelLos 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:
states:
draft
processing
fulfillment
completed
canceled
transitions:
place
draft → processing
process
processing → fulfillment
fulfill
fulfillment → completed
cancel
draft / processing / fulfillment → canceledLo importante en esta etapa no es memorizar el YAML.
Lo importante es comprender que el Workflow contiene una definición explícita de:
States
+
Allowed Transitions35. 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:
Transition:
Place Order
↓
Possible reactions:
├── Generate order number
├── Send email
├── Notify ERP
├── Create invoice
├── Reserve stock
└── Log commercial eventO:
Transition:
Complete Order
↓
Possible reactions:
├── Close fulfillment
├── Notify customer
├── Update CRM
└── Record analytics eventCommerce 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:
When order is placedo:
When payment is confirmedo:
When internal validation is completedEsto puede vincularse a una Transition clara.
Draft
↓
Place
↓
Validation
↓
Approve
↓
Send to ERPEsto 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:
Monday
Product price
100 EUR
Tuesday
Product price
90 EUREl 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:
Draft Ordery:
Placed OrderDurante Draft todavía tenemos una intención de compra.
Customer changes quantity
Customer removes products
Prices may refresh
Promotions may change
Availability may changeUna vez colocado el pedido, comenzamos a tratarlo como una transacción comercial.
Order Number
Placed Date
Commercial history
Operational processingEsta frontera es importante cuando diseñamos integraciones, auditoría y pricing.
39. No modificar silenciosamente pedidos históricos
Supongamos:
Order #1001
Placed:
January 2026
Product:
100 EURMeses después el producto cuesta:
120 EUREl Order histórico debe continuar reflejando lo que realmente ocurrió:
Order #1001
Unit Price:
100 EURUn 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:
Drupal Commerce
↓
Order placed
↓
ERP
↓
Warehouse
↓
Carrier
↓
DeliveredCommerce podría limitarse a mantener:
Fulfillment
↓
Completedmientras 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.
¿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 StateEsto ayuda a evitar workflows innecesariamente complicados.
43. Un modelo mental completo
Podemos visualizar todo el proceso así:
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:
ORDER
│
├── Checkout Flow
│
├── Payment Workflow
│
├── Pricing / Adjustments
│
└── Shipping / FulfillmentCommerce 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.
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?
↓
TransitionSi 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í:
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 pedidoLa idea más importante es mantener separados los diferentes procesos:
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 compradoDiseñ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.