# Shipping y Fullfilment en Drupal Commerce: Shipments, métodos, tarifas y entrega Enviado por [danieluxury](/es/user/1 "Ver perfil del usuario.") 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. ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext Length Width Height ``` Por ejemplo: ```plaintext 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: ```plaintext 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. ```plaintext Billing Profile = dónde facturamos Shipping Profile = dónde entregamos ``` Pueden coincidir: ```plaintext Billing Address Berlin Shipping Address Berlin ``` pero también pueden ser diferentes: ```plaintext 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: ```plaintext Order #1001 Items ├── Laptop × 1 ├── Mouse × 2 └── Monitor × 1 Shipment #1 ├── Laptop × 1 ├── Mouse × 2 └── Monitor × 1 ``` En el caso más sencillo: ```plaintext 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: ```plaintext Order #1001 Laptop Mouse Desk ``` El Laptop y Mouse se encuentran en un almacén. El Desk se encuentra en otro. Podemos terminar con: ```plaintext ORDER #1001 │ ├── Shipment #1 │ ├── Laptop │ └── Mouse │ └── Shipment #2 └── Desk ``` Cada Shipment puede tener características diferentes. Por ejemplo: ```plaintext 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: ```plaintext 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: ```plaintext Shipment Type Default ``` o en una implementación más especializada: ```plaintext 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: ```plaintext 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: ```plaintext Shipment ↓ Shipping Method ↓ Rate calculation ↓ Shipping Rate ``` --- ## 12. Shipping Method no significa necesariamente transportista Esta diferencia es importante. Un Shipping Method podría representar: ```plaintext Flat Rate Shipping ``` sin consultar a ningún transportista. Por ejemplo: ```plaintext Germany Standard Shipping 5 EUR ``` Pero también puede representar una integración externa: ```plaintext UPS Shipment data ↓ UPS API ↓ Available services and rates ``` Por tanto: ```plaintext 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: ```plaintext Standard Shipping Germany 5 EUR ``` O: ```plaintext Express Shipping Germany 15 EUR ``` Durante Checkout: ```plaintext 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. ```plaintext Order Product A Product B Product C Shipping: 10 EUR ``` Conceptualmente: ```plaintext 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: ```plaintext Shipping 2 EUR per item ``` Entonces: ```plaintext 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: ```plaintext 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: ```plaintext Carrier / Shipping integration UPS Available services ├── UPS Standard ├── UPS Express └── UPS Express Saver ``` O: ```plaintext Store-defined shipping ├── Standard Delivery ├── Express Delivery └── Free Delivery ``` La terminología exacta depende del plugin utilizado, pero conceptualmente debemos distinguir: ```plaintext 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: ```plaintext Service: Standard Shipping Amount: 8 EUR ``` O: ```plaintext Service: UPS Express Amount: 22.40 EUR ``` Durante Checkout podemos mostrar varias Rates: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext DHL Germany Available if: Shipping Country = Germany ``` Otro: ```plaintext Freight Delivery Available if: Weight > 50 kg ``` --- ## 21. Shipping Zones Muchos negocios organizan sus tarifas mediante zonas geográficas. Por ejemplo: ```plaintext Zone A Germany Austria Zone B France Belgium Netherlands Zone C Rest of EU ``` Y posteriormente: ```plaintext 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: ```plaintext Country Germany Postal Code 10115 ``` para decidir: ```plaintext 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: ```plaintext 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: ```plaintext Order Items ↓ Variations ↓ Weight ↓ Shipment Weight ↓ Rate Calculation ``` --- ## 24. Shipping según valor del pedido Podemos tener: ```plaintext Order subtotal < 100 EUR Shipping 8 EUR ``` y: ```plaintext 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: ```plaintext Shipping = 0 EUR ``` pero comercialmente puede tener diferentes causas. Por ejemplo: ```plaintext Shipping Method Free Pickup 0 EUR ``` o: ```plaintext 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: ```plaintext ¿El servicio siempre cuesta cero? ↓ Free Shipping Method ¿Normalmente tiene coste pero una promoción lo elimina? ↓ Shipping Promotion ``` Por ejemplo: ```plaintext 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: ```plaintext Store Pickup ``` Conceptualmente: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext Order 5 Books 2 Laptops 1 Monitor ``` Puede ser imposible enviarlo todo en una sola caja. Podemos terminar con: ```plaintext 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. ```plaintext 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: ```plaintext Laptop Battery Large Industrial Machine ``` Podemos tener restricciones diferentes. ```plaintext 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: ```plaintext T-Shirt Laptop Industrial Machine ``` Quizás no exista un único servicio capaz de enviarlos todos juntos. Podríamos necesitar: ```plaintext 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. ```plaintext Warehouse Berlin Warehouse Munich Warehouse Vienna ``` Un Order puede contener productos disponibles en diferentes ubicaciones. ```plaintext Order Product A → Berlin Product B → Munich Product C → Berlin ``` Podemos necesitar: ```plaintext 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. ```plaintext 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: ```plaintext DHL Express 20 EUR ``` Eso significa que conocemos: ```plaintext Shipping option + Shipping cost ``` Pero todavía no hemos: ```plaintext Picked product Packed product Created shipping label Handed package to DHL Delivered product ``` Por tanto: ```plaintext Shipping Rate Calculation ≠ Fulfillment ``` --- ## 36. Fulfillment Fulfillment representa el proceso mediante el cual cumplimos aquello que vendimos. Para productos físicos: ```plaintext Order placed ↓ Warehouse receives order ↓ Stock allocated ↓ Picking ↓ Packing ↓ Shipping ↓ Delivery ``` Para un producto digital: ```plaintext Order placed ↓ Payment confirmed ↓ License generated ↓ Access delivered ``` Para un servicio: ```plaintext 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: ```plaintext Order placed ↓ Send to ERP ``` Y posteriormente: ```plaintext ERP ↓ Warehouse ↓ Picking ↓ Packing ↓ Carrier ↓ Delivery ``` Commerce podría recibir únicamente información de retorno como: ```plaintext 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: ```plaintext 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: ```plaintext Shipment #1001 Carrier: DHL Tracking Number: JD014600006281234567 ``` Esto permite mostrar al cliente: ```plaintext Your order has shipped. Tracking: JD014600006281234567 ``` El tracking pertenece conceptualmente al Shipment, no al Product. --- ## 40. Varios Shipments significan varios Trackings Por ejemplo: ```plaintext Order #1001 Shipment #1 UPS Tracking: UPS123 Shipment #2 DHL Tracking: DHL456 ``` Por eso un único campo: ```plaintext 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: ```plaintext Draft ↓ Ready ↓ Shipped ↓ Delivered ``` No debemos confundir esto con el Order Workflow. ```plaintext Order State ≠ Shipment State ``` Un Order podría tener varios Shipments en diferentes situaciones. --- ## 42. Ejemplo de varios estados simultáneos Podemos tener: ```plaintext 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: ```plaintext 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: ```plaintext Draft ↓ Place ↓ Fulfillment ↓ Fulfill ↓ Completed ``` El estado: ```plaintext Fulfillment ``` puede representar el periodo durante el cual: ```plaintext 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: ```plaintext Package leaves warehouse ``` Otras cuando: ```plaintext 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: ```plaintext Authorize payment ↓ Prepare shipment ↓ Capture payment ↓ Ship ``` O: ```plaintext Capture payment ↓ Send order to warehouse ↓ Ship ``` Otra empresa podría utilizar: ```plaintext Ship ↓ Invoice ↓ Payment Net 30 ``` Especialmente en B2B. No debemos asumir que siempre: ```plaintext Payment ↓ Shipping ``` ocurre exactamente de la misma forma. --- ## 46. Shipping y Taxes El transporte también puede tener implicaciones fiscales. Por ejemplo: ```plaintext 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: ```plaintext Orders over 100 EUR ↓ Free Standard Shipping ``` O: ```plaintext Coupon: FREESHIPPING ↓ Shipping discount ``` Debemos distinguir nuevamente: ```plaintext Shipping Rate ↓ precio normal del transporte Shipping Promotion ↓ beneficio comercial sobre ese precio ``` --- ## 48. No codificar todas las tarifas manualmente Supongamos que tenemos: ```plaintext 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: ```plaintext 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: ```plaintext Commerce Shipping ↓ Carrier Plugin ↓ Carrier API ``` Por ejemplo: ```plaintext 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. ```plaintext Shipping ├── DHL ├── UPS └── FedEx ``` Durante Checkout podríamos consultar: ```plaintext 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. ```plaintext Product Variation T-Shirt Black / M Weight: 0.3 kg ``` El cliente añade: ```plaintext 2 × T-Shirt ``` Durante Checkout: ```plaintext Shipping Address Berlin Germany ``` Commerce crea o actualiza: ```plaintext Shipment Weight: 0.6 kg ``` Y ofrece: ```plaintext Standard Shipping 5 EUR Express Shipping 12 EUR ``` El cliente selecciona: ```plaintext Standard Shipping 5 EUR ``` El Order termina: ```plaintext Products 50 EUR Shipping 5 EUR Tax ... Total ... ``` --- ## 53. Ejemplo con envío gratuito Supongamos: ```plaintext Order subtotal 150 EUR ``` La regla comercial es: ```plaintext Orders ≥ 100 EUR ↓ Free Standard Shipping ``` Podemos conceptualmente terminar con: ```plaintext 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: ```plaintext Delivery Address Customer Warehouse Munich ``` El proceso puede ser: ```plaintext 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: ```plaintext Delivery terms Included in contract ``` o incluso: ```plaintext Shipping calculated later ``` El modelo debe seguir al negocio. --- ## 55. Ejemplo multi-warehouse Supongamos: ```plaintext Order #2001 Product A Warehouse Germany Product B Warehouse Austria ``` Fulfillment: ```plaintext 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: ```plaintext Laptop 1,000 EUR ``` Durante Checkout: ```plaintext Delivery Method ○ DHL Standard 8 EUR ● Pickup Berlin Free ``` El proceso de fulfillment puede ser: ```plaintext 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: ```plaintext 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: ```plaintext Rate calculation ``` Otro podría ofrecer: ```plaintext 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: ```plaintext 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: ```plaintext Shipment shipped ↓ Order completed ``` Quizás existe: ```plaintext Shipment #2 Still preparing ``` O: ```plaintext 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. ```plaintext Delivered ↓ Customer requests return ↓ Return authorized ↓ Product shipped back ↓ Warehouse receives product ↓ Refund ``` Debemos separar nuevamente: ```plaintext 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: ```plaintext Customer orders Product A × 5 Warehouse Germany Stock: 3 Warehouse Austria Stock: 10 ``` El sistema podría decidir: ```plaintext 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: ```plaintext 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: ```plaintext ¿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. ```plaintext 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: ```plaintext 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. ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext 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. ## Course navigation: Drupal Commerce Chapter 9 of 11 - [ ← Anterior Payments en Drupal Commerce: Gateways, Payment Methods, autorización, captura y reembolsos ](/es/payments-en-drupal-commerce-gateways-payment-methods-autorizacion-captura-y-reembolsos) - [ Siguiente → Crear una tienda Drupal Commerce desde cero: instalación y configuración inicial ](/es/crear-una-tienda-drupal-commerce-desde-cero-instalacion-y-configuracion-inicial) [↑ Course index](/es/node/43)