Shipping y Fullfilment en Drupal Commerce: Shipments, métodos, tarifas y entrega

Enviado por danieluxury el Vie, 25 Sep 2026 - 12:06

Después de estudiar Products, Orders, Checkout y Payments podemos abordar la otra gran parte de una tienda de productos físicos: Shipping y Fulfillment.

A primera vista ambos conceptos pueden parecer equivalentes.

Sin embargo, representan responsabilidades diferentes.

Shipping
= cómo transportamos los productos


Fulfillment
= cómo cumplimos la obligación
  comercial adquirida con el cliente

En una tienda tradicional el fulfillment puede incluir:

Order placed
     ↓
Stock reservation
     ↓
Picking
     ↓
Packing
     ↓
Shipping
     ↓
Delivery
     ↓
Order completed

Shipping es solamente una parte de ese proceso.

Comprender esta diferencia es fundamental para diseñar correctamente Commerce, especialmente cuando intervienen almacenes, ERP, diferentes transportistas o múltiples envíos para un mismo pedido.

1. Commerce Core y Commerce Shipping

Drupal Commerce Core proporciona las entidades y sistemas principales del comercio electrónico.

El soporte específico para envío de productos físicos se incorpora mediante Commerce Shipping.

Conceptualmente:

Drupal Commerce
      │
      ├── Products
      ├── Orders
      ├── Checkout
      ├── Payments
      └── Pricing

            +

Commerce Shipping
      │
      ├── Physical products
      ├── Shipments
      ├── Shipping Methods
      ├── Rates
      └── Shipping checkout integration

Esta separación es coherente con la arquitectura modular de Commerce.

Una tienda de productos digitales no necesita instalar un sistema de Shipping.

2. Qué significa que un producto sea shippable

No todas las Product Variations representan algo que necesita transporte físico.

Por ejemplo:

Book
→ Shippable


Laptop
→ Shippable


T-Shirt
→ Shippable


eBook
→ Not shippable


Software License
→ Not shippable


Consulting Service
→ Not shippable

Commerce Shipping permite definir Product Variation Types como productos físicos.

Esto permite añadir información necesaria para Shipping, por ejemplo:

Weight

Dimensions

La necesidad exacta dependerá del sistema utilizado para calcular el transporte.

3. El peso pertenece normalmente a la Variation

Recordemos nuestra regla de modelado.

Si diferentes unidades comprables tienen diferentes características físicas:

Product
Laptop Pro

Variations

16 GB / 512 GB
Weight: 1.40 kg


32 GB / 2 TB
Weight: 1.45 kg

el peso pertenece normalmente a la Product Variation.

El Shipping system puede utilizar posteriormente esa información para calcular una tarifa.

4. Dimensiones

Dependiendo del transportista o integración también podemos necesitar:

Length

Width

Height

Por ejemplo:

Product Variation

SKU:
CHAIR-001

Weight:
12 kg

Dimensions:
70 × 60 × 90 cm

Esta información puede intervenir en procesos como:

Selección de packaging
Cálculo de peso volumétrico
Restricciones de transportista
Cálculo de tarifas

5. Shipping Profile

Para calcular un envío necesitamos saber dónde debemos entregar los productos.

Commerce utiliza perfiles del cliente para representar esta información.

Conceptualmente:

Customer
   │
   └── Shipping Profile
          │
          ├── Name
          ├── Company
          ├── Address
          ├── City
          ├── Postal Code
          └── Country

Durante Checkout el cliente proporciona o selecciona esta dirección.

Ese dato puede determinar:

Qué Shipping Methods están disponibles
Qué transportistas podemos utilizar
Cuánto cuesta el transporte
Qué restricciones geográficas existen

6. Billing Profile no es Shipping Profile

Debemos mantener separados ambos conceptos.

Billing Profile
= dónde facturamos


Shipping Profile
= dónde entregamos

Pueden coincidir:

Billing Address
Berlin

Shipping Address
Berlin

pero también pueden ser diferentes:

Billing Address
Company Headquarters
Munich


Shipping Address
Warehouse
Hamburg

Esto es especialmente habitual en B2B.

7. Shipment

Una de las entidades fundamentales de Commerce Shipping es el Shipment.

Un Shipment representa un conjunto de productos que serán enviados juntos.

Por ejemplo:

Order #1001

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


Shipment #1

├── Laptop × 1
├── Mouse × 2
└── Monitor × 1

En el caso más sencillo:

1 Order
   ↓
1 Shipment

Pero esa relación no tiene por qué ser siempre uno a uno.

8. Un Order puede tener varios Shipments

Supongamos:

Order #1001

Laptop
Mouse
Desk

El Laptop y Mouse se encuentran en un almacén.

El Desk se encuentra en otro.

Podemos terminar con:

ORDER #1001
     │
     ├── Shipment #1
     │      ├── Laptop
     │      └── Mouse
     │
     └── Shipment #2
            └── Desk

Cada Shipment puede tener características diferentes.

Por ejemplo:

Shipment #1

Carrier:
UPS

Tracking:
UPS123456


Shipment #2

Carrier:
DHL Freight

Tracking:
DHL987654

Esta separación es muy importante para tiendas con fulfillment complejo.

9. Por qué Shipment es una entidad independiente

Podríamos preguntarnos:

¿Por qué no guardar simplemente el método de envío directamente en el Order?

Porque un Order puede contener múltiples entregas.

Además, cada Shipment puede necesitar información propia como:

Shipping Profile
Shipping Method
Shipping Service
Shipping Rate
Weight
Items
Tracking information
Estado

Conceptualmente:

Order
= transacción comercial


Shipment
= unidad logística de envío

10. Shipment Type

Al igual que otras entidades de Commerce, los Shipments pueden tener diferentes tipos.

Podríamos tener:

Shipment Type

Default

o en una implementación más especializada:

Parcel Shipment

Freight Shipment

Store Pickup

La necesidad de diferentes Shipment Types dependerá de las diferencias reales de estructura y comportamiento.

Como siempre, no debemos crear tipos adicionales si no existe una razón funcional.

11. Shipping Method

Un Shipping Method representa una forma disponible de calcular y ofrecer transporte.

Por ejemplo:

Standard Shipping

Express Shipping

Free Shipping

UPS

FedEx

DHL

Un Shipping Method define cómo obtenemos una tarifa y bajo qué condiciones está disponible.

Conceptualmente:

Shipment
     ↓
Shipping Method
     ↓
Rate calculation
     ↓
Shipping Rate

12. Shipping Method no significa necesariamente transportista

Esta diferencia es importante.

Un Shipping Method podría representar:

Flat Rate Shipping

sin consultar a ningún transportista.

Por ejemplo:

Germany

Standard Shipping
5 EUR

Pero también puede representar una integración externa:

UPS

Shipment data
     ↓
UPS API
     ↓
Available services and rates

Por tanto:

Shipping Method
= mecanismo para determinar
  servicios y tarifas


Carrier
= empresa que realiza
  físicamente el transporte

13. Flat Rate Shipping

El modelo más sencillo consiste en utilizar una tarifa fija.

Por ejemplo:

Standard Shipping

Germany

5 EUR

Express Shipping

Germany

15 EUR

Durante Checkout:

Shipping Method

○ Standard Shipping    5 EUR

● Express Shipping    15 EUR

Para muchas tiendas pequeñas este modelo puede ser suficiente.

14. Flat rate por pedido

Podemos cobrar una tarifa fija independientemente del número de productos.

Order

Product A
Product B
Product C

Shipping:
10 EUR

Conceptualmente:

1 Shipment
        ↓
Flat Rate
        ↓
10 EUR

15. Flat rate por item

Otro modelo puede calcular el envío según la cantidad de productos.

Por ejemplo:

Shipping
2 EUR per item

Entonces:

3 items
×
2 EUR
────────
6 EUR shipping

La estrategia correcta depende del modelo comercial.

16. Carrier-calculated shipping

Para cálculos más precisos podemos consultar APIs externas.

Por ejemplo:

Shipment

From:
Berlin

To:
Munich

Weight:
8 kg

Dimensions:
40 × 30 × 20 cm

        ↓

Carrier API

        ↓

Services

Standard
8.50 EUR

Express
18.20 EUR

El usuario puede seleccionar posteriormente uno de los servicios disponibles.

17. Shipping Service

Debemos distinguir entre el mecanismo de Shipping y el servicio concreto ofrecido al cliente.

Por ejemplo:

Carrier / Shipping integration

UPS

Available services

├── UPS Standard
├── UPS Express
└── UPS Express Saver

Store-defined shipping

├── Standard Delivery
├── Express Delivery
└── Free Delivery

La terminología exacta depende del plugin utilizado, pero conceptualmente debemos distinguir:

Cómo calculamos / obtenemos las opciones
        ↓
Shipping Method


Qué opción concreta selecciona el cliente
        ↓
Shipping Service / Rate

18. Shipping Rate

Una tarifa de Shipping representa normalmente una opción concreta junto con su importe.

Por ejemplo:

Service:
Standard Shipping

Amount:
8 EUR

Service:
UPS Express

Amount:
22.40 EUR

Durante Checkout podemos mostrar varias Rates:

Shipping

○ Standard
  3-5 days
  8 EUR


● Express
  1-2 days
  18 EUR

19. Shipping Adjustment

El importe del Shipping termina afectando al total del Order.

Recordemos el sistema de Adjustments:

Products
100 EUR

Promotion
-10 EUR

Shipping
+8 EUR

Tax
+18 EUR
────────────────
Total
116 EUR

El coste del transporte puede aparecer como un Shipping Adjustment.

Así mantenemos separado:

Product Price

Tax

Promotion

Shipping

en lugar de modificar arbitrariamente el precio del producto.

20. Disponibilidad de un Shipping Method

No todos los métodos deberían estar disponibles para todos los pedidos.

Podemos necesitar condiciones basadas en:

Store
Country
Customer
Product
Order Type
Weight
Order total

Por ejemplo:

DHL Germany

Available if:

Shipping Country
= Germany

Otro:

Freight Delivery

Available if:

Weight
> 50 kg

21. Shipping Zones

Muchos negocios organizan sus tarifas mediante zonas geográficas.

Por ejemplo:

Zone A

Germany
Austria


Zone B

France
Belgium
Netherlands


Zone C

Rest of EU

Y posteriormente:

Zone A
5 EUR


Zone B
10 EUR


Zone C
15 EUR

La implementación concreta puede variar, pero durante Discovery debemos identificar claramente las reglas geográficas.

22. Shipping según Postal Code

En algunos negocios un país no proporciona suficiente precisión.

Podemos necesitar:

Country
Germany

Postal Code
10115

para decidir:

Local Delivery
Available


Express Delivery
Available


Freight
Not available

Este tipo de reglas debe conocerse antes de seleccionar una integración de Shipping.

23. Shipping según peso

Otro modelo habitual:

0 - 5 kg
5 EUR


5 - 10 kg
8 EUR


10 - 20 kg
15 EUR


20+ kg
Freight calculation

Para ello necesitamos que las Product Variations dispongan de pesos correctos.

Conceptualmente:

Order Items
     ↓
Variations
     ↓
Weight
     ↓
Shipment Weight
     ↓
Rate Calculation

24. Shipping según valor del pedido

Podemos tener:

Order subtotal
< 100 EUR

Shipping
8 EUR

Order subtotal
≥ 100 EUR

Shipping
FREE

Esto puede representarse mediante condiciones, pricing o promociones dependiendo del modelo utilizado.

25. Free Shipping

Free Shipping puede parecer simplemente:

Shipping = 0 EUR

pero comercialmente puede tener diferentes causas.

Por ejemplo:

Shipping Method
Free Pickup
0 EUR

Standard Shipping
8 EUR

Promotion
Free shipping

        ↓

Shipping Promotion
-8 EUR

Ambos producen un coste final de 0 EUR, pero representan conceptos diferentes.

26. Free Shipping Method frente a Shipping Promotion

Podemos utilizar esta distinción:

¿El servicio siempre cuesta cero?
        ↓
Free Shipping Method


¿Normalmente tiene coste
pero una promoción lo elimina?
        ↓
Shipping Promotion

Por ejemplo:

Store Pickup
= siempre 0 EUR


UPS Standard
= normalmente 8 EUR

Order over 100 EUR
= promotion reduces shipping to 0

27. Store Pickup

No todos los mecanismos de entrega necesitan un transportista.

Podemos tener:

Store Pickup

Conceptualmente:

Order
   ↓
Customer selects
Store Pickup
   ↓
No carrier shipment
   ↓
Prepare products
   ↓
Customer collects

Desde el punto de vista comercial continúa existiendo un proceso de fulfillment, aunque no exista transporte a domicilio.

28. Local Delivery

Otro modelo puede ser:

Local Delivery

Available within:
20 km

El negocio realiza la entrega directamente.

No existe necesariamente una integración con UPS, DHL o FedEx.

Esto demuestra nuevamente que:

Shipping
≠
Carrier API

Una estrategia de Shipping puede ser completamente interna.

29. Packaging

En una operación logística real también debemos considerar cómo se agrupan los productos físicamente.

Supongamos:

Order

5 Books
2 Laptops
1 Monitor

Puede ser imposible enviarlo todo en una sola caja.

Podemos terminar con:

Shipment

Package 1
├── 5 Books
└── 1 Laptop


Package 2
└── 1 Laptop


Package 3
└── Monitor

El concepto de packaging puede ser importante para calcular correctamente tarifas de transportistas.

30. Order Item, Shipment y Package

Podemos distinguir conceptualmente tres niveles.

ORDER ITEM

¿Qué compró el cliente?


SHIPMENT

¿Qué enviaremos conjuntamente
a un destino?


PACKAGE

¿Cómo agrupamos físicamente
los productos para transportarlos?

No todos los proyectos necesitan modelar explícitamente los tres niveles.

La integración de Shipping utilizada determinará cuánto detalle necesitamos.

31. Un producto puede necesitar envío especial

Supongamos que vendemos:

Laptop

Battery

Large Industrial Machine

Podemos tener restricciones diferentes.

Laptop
→ Standard / Express


Battery
→ Restricted shipping


Industrial Machine
→ Freight only

Esto puede afectar qué Shipping Methods están disponibles.

32. Productos mezclados en un mismo Order

Un pedido puede contener:

T-Shirt

Laptop

Industrial Machine

Quizás no exista un único servicio capaz de enviarlos todos juntos.

Podríamos necesitar:

Order

├── Shipment #1
│   ├── T-Shirt
│   └── Laptop
│
└── Shipment #2
    └── Industrial Machine

Esto demuestra por qué Shipment es una entidad independiente del Order.

33. Multi-warehouse

Otro escenario frecuente es tener varios almacenes.

Warehouse Berlin

Warehouse Munich

Warehouse Vienna

Un Order puede contener productos disponibles en diferentes ubicaciones.

Order

Product A
→ Berlin


Product B
→ Munich


Product C
→ Berlin

Podemos necesitar:

Shipment #1
Berlin
├── Product A
└── Product C


Shipment #2
Munich
└── Product B

En proyectos avanzados, la creación de Shipments puede depender del sistema de inventario o ERP.

34. Dropshipping

Supongamos ahora que algunos productos son enviados directamente por el proveedor.

Customer
   ↓
Drupal Commerce
   ↓
Order

        ├── Own Warehouse
        │       ↓
        │   Shipment #1
        │
        └── Supplier
                ↓
            Shipment #2

El cliente realizó una única compra.

Pero el fulfillment puede estar distribuido entre múltiples organizaciones.

35. Shipping Calculation no es Fulfillment

Esta es probablemente la separación más importante del artículo.

Durante Checkout podemos calcular:

DHL Express
20 EUR

Eso significa que conocemos:

Shipping option
+
Shipping cost

Pero todavía no hemos:

Picked product

Packed product

Created shipping label

Handed package to DHL

Delivered product

Por tanto:

Shipping Rate Calculation
        ≠
Fulfillment

36. Fulfillment

Fulfillment representa el proceso mediante el cual cumplimos aquello que vendimos.

Para productos físicos:

Order placed
     ↓
Warehouse receives order
     ↓
Stock allocated
     ↓
Picking
     ↓
Packing
     ↓
Shipping
     ↓
Delivery

Para un producto digital:

Order placed
     ↓
Payment confirmed
     ↓
License generated
     ↓
Access delivered

Para un servicio:

Order placed
     ↓
Appointment scheduled
     ↓
Service provided

Por tanto Fulfillment es un concepto más amplio que Shipping.

37. Commerce no necesita gestionar todo el Fulfillment

En muchos proyectos Commerce solamente necesita llegar hasta:

Order placed
        ↓
Send to ERP

Y posteriormente:

ERP
 ↓
Warehouse
 ↓
Picking
 ↓
Packing
 ↓
Carrier
 ↓
Delivery

Commerce podría recibir únicamente información de retorno como:

Shipment created

Tracking number

Shipment delivered

Esto puede ser mucho mejor que intentar reproducir un Warehouse Management System dentro de Drupal.

38. Source of Truth para Shipping y Fulfillment

Durante Discovery debemos definir quién es responsable de cada dato.

Por ejemplo:

Shipping Address
→ Drupal Commerce


Shipping Method selected
→ Drupal Commerce


Product Weight
→ PIM


Inventory
→ ERP


Warehouse assignment
→ ERP


Shipping Label
→ Carrier system


Tracking Number
→ Carrier / ERP


Order status
→ Drupal Commerce

Esta matriz evita integraciones ambiguas.

39. Tracking Number

Una vez despachado el Shipment normalmente obtenemos un identificador de seguimiento.

Por ejemplo:

Shipment #1001

Carrier:
DHL

Tracking Number:
JD014600006281234567

Esto permite mostrar al cliente:

Your order has shipped.

Tracking:
JD014600006281234567

El tracking pertenece conceptualmente al Shipment, no al Product.

40. Varios Shipments significan varios Trackings

Por ejemplo:

Order #1001

Shipment #1
UPS
Tracking: UPS123


Shipment #2
DHL
Tracking: DHL456

Por eso un único campo:

Order
field_tracking_number

puede ser un mal modelo para tiendas donde existen múltiples Shipments.

41. Shipment State

En implementaciones donde necesitamos seguir el ciclo logístico, un Shipment también puede tener su propio estado.

Conceptualmente:

Draft
   ↓
Ready
   ↓
Shipped
   ↓
Delivered

No debemos confundir esto con el Order Workflow.

Order State
        ≠
Shipment State

Un Order podría tener varios Shipments en diferentes situaciones.

42. Ejemplo de varios estados simultáneos

Podemos tener:

Order #1001

State:
Fulfillment


Shipment #1

State:
Shipped


Shipment #2

State:
Preparing

El Order todavía no está completamente cumplido porque existe un Shipment pendiente.

Cuando ambos finalizan:

Shipment #1
Delivered


Shipment #2
Delivered

        ↓

Order
Completed

La lógica exacta dependerá de nuestro proceso.

43. Shipping y Order Workflow

Recordemos el workflow de fulfillment:

Draft
   ↓
Place
   ↓
Fulfillment
   ↓
Fulfill
   ↓
Completed

El estado:

Fulfillment

puede representar el periodo durante el cual:

Warehouse prepares goods

Shipments are created

Labels generated

Packages dispatched

Cuando el negocio considera cumplida la obligación, el Order puede avanzar a Completed.

44. ¿Completed significa Shipped o Delivered?

Esta pregunta debe responderla el negocio.

Algunas empresas consideran completado un pedido cuando:

Package leaves warehouse

Otras cuando:

Carrier confirms delivery

Otras incluso pueden mantener estados posteriores para devoluciones.

No existe una respuesta universal.

La definición debe formar parte del Discovery.

45. Payment y Shipping

También necesitamos definir la relación entre ambos procesos.

Por ejemplo:

Authorize payment
       ↓
Prepare shipment
       ↓
Capture payment
       ↓
Ship

Capture payment
       ↓
Send order to warehouse
       ↓
Ship

Otra empresa podría utilizar:

Ship
  ↓
Invoice
  ↓
Payment Net 30

Especialmente en B2B.

No debemos asumir que siempre:

Payment
        ↓
Shipping

ocurre exactamente de la misma forma.

46. Shipping y Taxes

El transporte también puede tener implicaciones fiscales.

Por ejemplo:

Products
100 EUR

Shipping
10 EUR

El tratamiento fiscal de esos 10 EUR depende de las reglas aplicables al negocio.

Commerce permite que Taxes y Shipping participen separadamente en los cálculos del Order.

Las reglas fiscales concretas deben validarse según la jurisdicción correspondiente.

47. Shipping y Promotions

Shipping también puede participar en campañas comerciales.

Por ejemplo:

Orders over 100 EUR
        ↓
Free Standard Shipping

Coupon:
FREESHIPPING

        ↓

Shipping discount

Debemos distinguir nuevamente:

Shipping Rate
        ↓
precio normal del transporte


Shipping Promotion
        ↓
beneficio comercial sobre ese precio

48. No codificar todas las tarifas manualmente

Supongamos que tenemos:

Germany
5 EUR

Austria
8 EUR

France
10 EUR

Spain
12 EUR

Italy
11 EUR

Switzerland
18 EUR

Esta estructura puede ser perfectamente válida si el negocio realmente utiliza tarifas fijas.

Pero si el transportista cambia constantemente las tarifas según:

Weight
Dimensions
Postal Code
Fuel surcharge
Service
Date

mantener tablas manuales en Drupal puede no ser la mejor arquitectura.

Quizás debamos consultar directamente al Carrier o a un servicio intermediario.

49. Integraciones con carriers

Commerce Shipping puede extenderse mediante integraciones específicas.

Conceptualmente:

Commerce Shipping
       ↓
Carrier Plugin
       ↓
Carrier API

Por ejemplo:

Order / Shipment
       ↓
Weight + Destination
       ↓
UPS Integration
       ↓
UPS API
       ↓
Available Rates

La integración puede ofrecer funcionalidades adicionales como:

Rate calculation
Service discovery
Label creation
Tracking

Las capacidades exactas dependen del módulo y proveedor utilizados.

50. Multi-carrier

Una tienda puede trabajar con varios transportistas.

Shipping

├── DHL
├── UPS
└── FedEx

Durante Checkout podríamos consultar:

DHL Standard
10 EUR


UPS Standard
9 EUR


FedEx Express
18 EUR

y presentar las opciones disponibles.

También podemos utilizar servicios externos que agregan múltiples carriers detrás de una única API.

51. No seleccionar un Carrier antes del Discovery

Al igual que con Payments, no deberíamos comenzar preguntando:

¿Qué módulo de DHL instalamos?

Primero necesitamos conocer:

¿A qué países enviamos?
¿Qué transportistas utiliza actualmente el cliente?
¿Tiene contratos propios?
¿Cómo se calculan las tarifas?
¿Necesitamos labels?
¿Necesitamos tracking?
¿Necesitamos pickups?
¿Existen varios almacenes?
¿Existen productos especiales?

Solamente después podemos evaluar la integración correcta.

52. Ejemplo B2C sencillo

Supongamos una tienda de camisetas.

Product Variation

T-Shirt Black / M

Weight:
0.3 kg

El cliente añade:

2 × T-Shirt

Durante Checkout:

Shipping Address

Berlin
Germany

Commerce crea o actualiza:

Shipment

Weight:
0.6 kg

Y ofrece:

Standard Shipping
5 EUR


Express Shipping
12 EUR

El cliente selecciona:

Standard Shipping
5 EUR

El Order termina:

Products
50 EUR

Shipping
5 EUR

Tax
...

Total
...

53. Ejemplo con envío gratuito

Supongamos:

Order subtotal
150 EUR

La regla comercial es:

Orders ≥ 100 EUR
        ↓
Free Standard Shipping

Podemos conceptualmente terminar con:

Standard Shipping
8 EUR

Shipping Promotion
-8 EUR

Final Shipping
0 EUR

Esto conserva la información de cuánto costaba originalmente el servicio y qué promoción se aplicó.

54. Ejemplo B2B

Supongamos una empresa que vende componentes industriales.

El cliente selecciona:

Delivery Address

Customer Warehouse
Munich

El proceso puede ser:

Order placed
        ↓
Send to ERP
        ↓
ERP selects warehouse
        ↓
ERP creates shipment
        ↓
DHL Freight
        ↓
Tracking returned to Drupal
        ↓
Customer notification

Drupal Commerce quizá no necesite calcular el Shipping Rate en tiempo real.

Podemos tener:

Delivery terms
Included in contract

o incluso:

Shipping calculated later

El modelo debe seguir al negocio.

55. Ejemplo multi-warehouse

Supongamos:

Order #2001

Product A
Warehouse Germany


Product B
Warehouse Austria

Fulfillment:

ORDER #2001
     │
     ├── Shipment #1
     │      Germany
     │      ↓
     │      DHL
     │
     └── Shipment #2
            Austria
            ↓
            Austrian Post

El cliente sigue viendo una sola compra, aunque internamente existen dos operaciones logísticas.

56. Ejemplo de Store Pickup

El cliente compra:

Laptop
1,000 EUR

Durante Checkout:

Delivery Method

○ DHL Standard       8 EUR

● Pickup Berlin      Free

El proceso de fulfillment puede ser:

Order placed
     ↓
Store prepares product
     ↓
Ready for pickup
     ↓
Customer collects
     ↓
Completed

No existe transporte externo, pero sigue existiendo fulfillment.

57. Shipping Labels

En operaciones más automatizadas podemos necesitar crear etiquetas de transporte.

Conceptualmente:

Shipment
   ↓
Carrier API
   ↓
Create label
   ↓
PDF / Label
   ↓
Attach to package

La capacidad de crear labels depende de la integración utilizada.

No debemos asumir que cualquier módulo que calcule tarifas también genera etiquetas.

58. Rate Calculation y Label Creation son funcionalidades diferentes

Un módulo podría ofrecer solamente:

Rate calculation

Otro podría ofrecer:

Rate calculation
+
Labels
+
Tracking

Por eso debemos evaluar integraciones mediante requisitos concretos.

59. Shipping Notifications

Cuando un Shipment cambia podemos necesitar notificar al cliente.

Por ejemplo:

Shipment
        ↓
Shipped
        ↓
Email


Your order has shipped.

Carrier:
DHL

Tracking:
ABC123

Esta notificación pertenece al proceso de fulfillment, no necesariamente al Checkout.

60. Shipping no debería gobernar todo el Order

Supongamos que un Shipment fue enviado.

No debemos asumir automáticamente:

Shipment shipped
        ↓
Order completed

Quizás existe:

Shipment #2
Still preparing

Payment
Still pending

Las reglas para completar el Order deben corresponder al proceso comercial real.

61. Returns

Después de entregar un producto puede existir el camino inverso.

Delivered
   ↓
Customer requests return
   ↓
Return authorized
   ↓
Product shipped back
   ↓
Warehouse receives product
   ↓
Refund

Debemos separar nuevamente:

Return
= movimiento/logística del producto


Refund
= movimiento financiero

Una tienda con procesos complejos de devoluciones puede necesitar módulos o desarrollo adicional para modelarlos.

62. Inventario y Shipping

Shipping depende frecuentemente de información de inventario.

Por ejemplo:

Customer orders
Product A × 5


Warehouse Germany
Stock: 3


Warehouse Austria
Stock: 10

El sistema podría decidir:

Shipment #1
Germany
3 units


Shipment #2
Austria
2 units

Pero esta lógica pertenece normalmente al sistema de inventario o fulfillment, no simplemente al cálculo de Shipping Rate.

63. Shipping e Inventory son dominios diferentes

Podemos pensar:

Inventory
= dónde y cuánto producto tenemos


Shipping
= cómo lo transportaremos


Fulfillment
= cómo cumpliremos el pedido

Están estrechamente relacionados, pero representan problemas diferentes.

64. Preguntas para Shipping Discovery

Productos

¿Qué productos son físicos?
¿Disponemos de peso?
¿Necesitamos dimensiones?
¿Existen productos con restricciones?

Destinos

¿A qué países enviamos?
¿Existen zonas?
¿Existen restricciones por Postal Code?

Tarifas

¿Tarifa fija?
¿Por item?
¿Por peso?
¿Por valor del Order?
¿Carrier-calculated?

Transportistas

¿Qué carriers utiliza el cliente?
¿Existen contratos comerciales?
¿Necesitamos múltiples carriers?

Servicios

¿Standard?
¿Express?
¿Same day?
¿Store Pickup?

Promociones

¿Existe Free Shipping?
¿Desde qué importe?
¿Necesita coupon?

Fulfillment

¿Quién prepara el pedido?
¿Drupal?
¿ERP?
¿Warehouse Management System?
¿Proveedor externo?

Warehouses

¿Existe uno o varios?
¿Quién determina desde dónde se envía?

Shipments

¿Puede un Order generar varios Shipments?
¿Se permiten envíos parciales?

Tracking

¿Necesitamos Tracking Number?
¿Quién lo proporciona?
¿Necesitamos actualizar estados automáticamente?

Labels

¿Drupal debe generar shipping labels?
¿Las genera el ERP?
¿Las genera el carrier?

Returns

¿Existen devoluciones?
¿Quién las gestiona?
¿Necesitamos return labels?

65. Una matriz para separar conceptos

Podemos utilizar esta guía mental:

¿Dónde entregamos?
        ↓
Shipping Profile


¿Qué productos enviaremos juntos?
        ↓
Shipment


¿Cómo calculamos las opciones
de transporte?
        ↓
Shipping Method


¿Qué opción concreta utilizamos?
        ↓
Shipping Service / Rate


¿Cuánto cuesta?
        ↓
Shipping Adjustment


¿Cómo agrupamos físicamente
los productos?
        ↓
Package


¿Cómo seguimos el envío?
        ↓
Tracking


¿Cómo cumplimos toda la compra?
        ↓
Fulfillment

66. Modelo mental completo

Podemos ahora conectar Shipping con todo lo estudiado en la serie.

PRODUCT
   ↓
PRODUCT VARIATION
   │
   ├── Weight
   └── Dimensions
   ↓
ADD TO CART
   ↓
ORDER ITEM
   ↓
ORDER / CART
   ↓
CHECKOUT
   │
   ├── Shipping Profile
   │
   ├── Shipping Method
   │
   └── Shipping Rate
   ↓
SHIPMENT
   ↓
SHIPPING ADJUSTMENT
   ↓
PAYMENT
   ↓
PLACE ORDER
   ↓
FULFILLMENT
   │
   ├── Warehouse
   ├── Picking
   ├── Packing
   ├── Carrier
   ├── Tracking
   └── Delivery
   ↓
ORDER COMPLETED

En una arquitectura empresarial podemos extenderlo:

                    PIM
                     │
                     ↓
PRODUCTS ─────→ DRUPAL COMMERCE
                     │
                     ↓
                   ORDER
                     │
                     ↓
                    ERP
                     │
            ┌────────┴────────┐
            ↓                 ↓
      Warehouse A       Warehouse B
            │                 │
            ↓                 ↓
       Shipment #1        Shipment #2
            │                 │
            ↓                 ↓
           DHL               UPS
            │                 │
            └────────┬────────┘
                     ↓
                  Customer

67. La regla de las cinco preguntas

Podemos resumir el diseño de Shipping mediante cinco preguntas.

1. ¿Qué necesita transporte?
        ↓
Physical Product Variation


2. ¿Dónde debemos entregarlo?
        ↓
Shipping Profile


3. ¿Qué enviaremos conjuntamente?
        ↓
Shipment


4. ¿Cómo y cuánto cuesta enviarlo?
        ↓
Shipping Method / Rate


5. ¿Cómo cumplimos finalmente
   la obligación con el cliente?
        ↓
Fulfillment

Conclusión

Shipping en Drupal Commerce es mucho más que añadir un precio de transporte al Checkout.

Debemos separar varias responsabilidades:

Physical Product
= producto que necesita entrega física


Shipping Profile
= destino


Shipment
= conjunto de productos enviados juntos


Shipping Method
= estrategia para obtener
  opciones y tarifas


Shipping Rate
= opción y precio concreto


Shipping Adjustment
= impacto económico en el Order


Tracking
= seguimiento de un Shipment


Fulfillment
= proceso completo para cumplir
  la compra

La distinción más importante es:

Shipping
= transporte


Fulfillment
= cumplimiento del pedido

Drupal Commerce puede participar en todo el proceso o limitarse a gestionar la transacción comercial y delegar fulfillment en sistemas especializados como ERP, WMS o proveedores logísticos.

La arquitectura correcta dependerá de dónde se encuentre el Source of Truth para productos, inventario, almacenes, Shipments y tracking.

Con este punto hemos recorrido prácticamente todo el flujo comercial principal:

Discovery
   ↓
Product Modeling
   ↓
Pricing
   ↓
Cart / Order
   ↓
Checkout
   ↓
Payment
   ↓
Shipping
   ↓
Fulfillment
   ↓
Completion

El siguiente paso lógico ya no es añadir otro concepto aislado.

Ahora podemos comenzar una nueva fase de la serie: configurar una tienda Drupal Commerce desde cero.

Partiremos de un Drupal limpio, instalaremos Commerce y construiremos progresivamente una tienda sencilla aplicando todas las decisiones arquitectónicas estudiadas hasta ahora: Store, Product Type, Variation Type, Attributes, Products, Pricing, Orders, Checkout, Payment y Shipping.