# Antes de configurar Drupal Commerce: Discovery del negocio y del modelo comercial Enviado por [danieluxury](/es/user/1 "Ver perfil del usuario.") el Vie, 25 Sep 2026 - 11:30 Configurar Drupal Commerce no debería comenzar creando un *Product Type*, una variación de producto o un método de pago. Antes de entrar en la interfaz administrativa necesitamos comprender cómo funciona realmente el negocio que queremos representar. Dos tiendas pueden vender aparentemente el mismo tipo de producto y, sin embargo, necesitar arquitecturas completamente diferentes. El objetivo de esta etapa es convertir las necesidades comerciales del cliente en un **modelo de negocio suficientemente claro** como para que posteriormente podamos traducirlo a la arquitectura de Drupal Commerce. --- ## 1. Empezar por el modelo de negocio, no por Commerce Drupal Commerce proporciona los componentes necesarios para construir un sistema de comercio electrónico, pero no puede decidir por nosotros cómo funciona el negocio. Antes de configurar nada debemos comprender cuestiones como: - ¿Qué vende la empresa? - ¿A quién vende? - ¿En qué países o mercados opera? - ¿Cómo determina sus precios? - ¿Cómo recibe los pagos? - ¿Cómo entrega los productos o servicios? - ¿Cómo gestiona los pedidos? - ¿Qué sistemas externos participan en el proceso? Una descripción inicial del negocio podría ser: > Vendemos productos técnicos a clientes profesionales y particulares en varios países europeos, con precios, impuestos y métodos de envío diferentes según el mercado. Esta pequeña descripción ya plantea muchas preguntas que posteriormente afectarán a la configuración de Commerce. --- ## 2. Identificar qué estamos vendiendo La primera pregunta aparentemente sencilla es: > ¿Qué vende el cliente? La respuesta puede ser mucho más compleja de lo que parece. Podemos vender: - Productos físicos - Productos digitales - Servicios - Suscripciones - Licencias - Entradas - Reservas - Membresías - Productos personalizados - Combinaciones de los anteriores Debemos comprender qué representa realmente una unidad comercializable dentro del negocio. Por ejemplo, la afirmación: > Vendemos puertas. todavía no nos proporciona suficiente información. Podríamos descubrir que existen diferentes modelos: ```plaintext Puerta Modelo A Puerta Modelo B Puerta Modelo C ``` y que cada modelo puede adquirirse en diferentes combinaciones: ```plaintext Puerta Modelo A ├── 80 × 200 / Blanco / Apertura izquierda ├── 80 × 200 / Blanco / Apertura derecha ├── 90 × 200 / Blanco / Apertura izquierda └── 90 × 200 / Blanco / Apertura derecha ``` En otro negocio, sin embargo, esas características podrían no representar productos diferentes, sino simplemente opciones introducidas durante el proceso de compra. Determinar esta diferencia será fundamental cuando posteriormente diseñemos los **Products** y **Product Variations** de Drupal Commerce. --- ## 3. Diferenciar producto comercial y presentación del producto Una decisión importante consiste en separar dos conceptos: - Lo que el cliente ve como producto. - Lo que realmente se compra. Por ejemplo: ```plaintext Producto visible Laptop Pro 14 Variaciones vendibles ├── 16 GB RAM / 512 GB SSD ├── 16 GB RAM / 1 TB SSD ├── 32 GB RAM / 1 TB SSD └── 32 GB RAM / 2 TB SSD ``` Para el usuario existe un único producto: **Laptop Pro 14**. Sin embargo, cada combinación puede tener: - SKU propio - Precio propio - Stock propio - Peso propio - Disponibilidad propia Esta distinción es una de las bases del modelado de productos en Commerce. --- ## 4. Identificar los atributos que modifican el producto Debemos determinar qué características pueden cambiar entre diferentes versiones de un producto. Por ejemplo: - Tamaño - Color - Material - Capacidad - Peso - Acabado - Orientación - Presentación No todos los campos de un producto deben convertirse en atributos comerciales. Por ejemplo: ```plaintext Color → puede definir una variación Tamaño → puede definir una variación SKU → identifica la variación Precio → pertenece a la variación Descripción → información del producto Documentación → información del producto Marca → clasificación Categoría → navegación ``` Durante el Discovery necesitamos averiguar cuáles de estas propiedades tienen consecuencias comerciales reales. --- ## 5. Comprender cómo se forman los precios El precio puede ser uno de los elementos más complejos de un proyecto de Commerce. No debemos asumir que un producto tiene simplemente un precio fijo. Necesitamos preguntar: - ¿Existe un único precio por producto? - ¿El precio depende de la variación? - ¿Depende del país? - ¿Depende de la moneda? - ¿Depende del tipo de cliente? - ¿Existen precios B2B y B2C? - ¿Existen listas de precios? - ¿Hay precios por volumen? - ¿Los precios incluyen impuestos? - ¿Proceden los precios de un ERP? - ¿Cambian frecuentemente? Un modelo relativamente simple podría ser: ```plaintext Producto ↓ Variación ↓ Precio ``` Pero un negocio más complejo podría necesitar algo similar a: ```plaintext Variación ↓ Precio base ↓ Mercado ↓ Tipo de cliente ↓ Cantidad ↓ Promoción ↓ Impuestos ↓ Precio final ``` Antes de implementar reglas de precios necesitamos comprender claramente este proceso. --- ## 6. Identificar quién compra No todos los clientes deben necesariamente recibir el mismo tratamiento. Debemos identificar los diferentes tipos de compradores. Por ejemplo: - Cliente particular - Empresa - Distribuidor - Mayorista - Cliente registrado - Cliente invitado - Cliente VIP Podrían existir diferencias en: - Precios - Impuestos - Catálogo disponible - Cantidad mínima de compra - Formas de pago - Condiciones de crédito - Promociones - Proceso de checkout Esto es especialmente importante en proyectos B2B. --- ## 7. Identificar los mercados donde se vende Una tienda puede operar en un único país o en muchos mercados diferentes. Necesitamos determinar: - ¿En qué países se vende? - ¿Existen regiones dentro de esos países? - ¿Qué monedas se utilizan? - ¿Qué idiomas se necesitan? - ¿Cambian los precios según el mercado? - ¿Cambian los productos disponibles? - ¿Cambian los impuestos? - ¿Cambian los métodos de pago? - ¿Cambian los métodos de envío? Por ejemplo: ```plaintext Germany ├── EUR ├── German ├── VAT Germany ├── DHL └── PayPal / Credit Card Switzerland ├── CHF ├── German / French ├── Swiss taxes ├── Swiss Post └── Credit Card ``` Esta información puede influir posteriormente en Stores, currencies, pricing, taxes, shipping y checkout. --- ## 8. Comprender los impuestos Los impuestos no deberían considerarse simplemente una configuración técnica. Forman parte del modelo comercial. Necesitamos preguntar: - ¿En qué países debe cobrar impuestos la empresa? - ¿Qué tipos de impuestos existen? - ¿Existen diferentes tasas según el producto? - ¿El precio mostrado incluye impuestos? - ¿Existen clientes exentos? - ¿Cómo funcionan las ventas B2B? - ¿De dónde obtenemos la ubicación fiscal del cliente? El objetivo durante esta fase no es determinar todavía cómo configuraremos cada tasa en Drupal Commerce. Primero necesitamos documentar las reglas fiscales que el sistema deberá representar. --- ## 9. Comprender las promociones y descuentos También debemos conocer cómo funciona la estrategia comercial del cliente. Algunos ejemplos: - Cupones - Descuentos porcentuales - Descuentos por importe fijo - Envío gratuito - Descuentos por cantidad - Promociones temporales - Promociones para determinados clientes - Comprar X y recibir Y - Descuentos por categoría Necesitamos descubrir tanto las promociones actuales como las que el departamento comercial probablemente quiera utilizar en el futuro. Por ejemplo: ```plaintext Si cantidad ≥ 10 → 5 % descuento Si cantidad ≥ 50 → 10 % descuento ``` O: ```plaintext Cliente pertenece a "Distribuidores" + Producto pertenece a "Herramientas" ↓ 15 % descuento ``` --- ## 10. Diseñar conceptualmente el carrito y el checkout Antes de configurar un Checkout Flow debemos entender cómo debería producirse la compra. Un proceso sencillo podría ser: ```plaintext Producto ↓ Carrito ↓ Datos del cliente ↓ Envío ↓ Pago ↓ Revisión ↓ Pedido completado ``` Pero otros negocios pueden requerir procesos diferentes. Por ejemplo: ```plaintext Carrito ↓ Datos de empresa ↓ Número fiscal ↓ Dirección ↓ Método de envío ↓ Purchase Order ↓ Revisión comercial ↓ Pedido confirmado ``` Debemos preguntar: - ¿Se permite checkout como invitado? - ¿Es obligatorio crear una cuenta? - ¿Qué datos necesitamos del cliente? - ¿Necesitamos dirección de facturación? - ¿Necesitamos una dirección de envío diferente? - ¿Cuándo se selecciona el envío? - ¿Cuándo se calcula el impuesto? - ¿Cuándo se realiza el pago? - ¿Existe una revisión antes de confirmar? --- ## 11. Identificar los métodos de pago Debemos documentar cómo puede pagar el cliente. Por ejemplo: - Tarjeta de crédito - PayPal - Transferencia bancaria - Pago contra entrega - Factura - Purchase Order - Proveedor de pagos regional Pero también necesitamos entender aspectos menos visibles: - ¿El pago es inmediato? - ¿Se autoriza primero y se captura posteriormente? - ¿Puede devolverse parcialmente? - ¿Quién realiza los reembolsos? - ¿Se necesita guardar información del método de pago? - ¿Qué ocurre si un pago falla? La elección de un proveedor de pagos debe realizarse después de comprender estas necesidades. --- ## 12. Comprender el envío y fulfillment Si existen productos físicos debemos analizar cómo llegan hasta el cliente. Necesitamos conocer: - Transportistas - Zonas de envío - Costos - Peso - Dimensiones - Envío gratuito - Recogida en tienda - Restricciones geográficas - Tiempos de entrega - Tracking Además debemos distinguir entre **shipping** y **fulfillment**. El envío representa normalmente cómo transportamos el producto, mientras que fulfillment describe el proceso más amplio de preparar y completar físicamente el pedido. Por ejemplo: ```plaintext Pedido recibido ↓ ERP / almacén ↓ Picking ↓ Packing ↓ Transportista ↓ Tracking ↓ Entregado ``` --- ## 13. Comprender el ciclo de vida del pedido Un pedido no simplemente existe o deja de existir. Normalmente pasa por diferentes estados. Por ejemplo: ```plaintext Draft ↓ Placed ↓ Paid ↓ Processing ↓ Shipped ↓ Completed ``` También pueden existir caminos alternativos: ```plaintext Placed ├── Cancelled ├── Payment failed └── Refunded ``` Necesitamos conocer: - ¿Cuándo consideramos que existe un pedido? - ¿Cuándo se confirma? - ¿Cuándo se paga? - ¿Quién puede cancelarlo? - ¿Quién puede modificarlo? - ¿Cuándo pasa al ERP? - ¿Cuándo se considera completado? Esto posteriormente influirá en los workflows de pedidos. --- ## 14. Stock e inventario También debemos determinar quién es responsable del inventario. Algunas posibilidades son: ```plaintext Drupal Commerce ↓ gestiona stock ``` o: ```plaintext ERP ↓ Stock ↓ Drupal Commerce ``` O incluso: ```plaintext ERP central │ ├── Warehouse Germany ├── Warehouse Austria └── Warehouse Switzerland ↓ Drupal Commerce ``` Preguntas importantes: - ¿Commerce será la fuente principal de inventario? - ¿Existe un ERP? - ¿Existen varios almacenes? - ¿Permitimos vender sin stock? - ¿Existen reservas de stock? - ¿Necesitamos mostrar disponibilidad? --- ## 15. Identificar los sistemas externos En proyectos comerciales es frecuente que Drupal Commerce sea solamente una pieza dentro de una arquitectura empresarial mayor. Por ejemplo: ```plaintext CRM ↑ │ PIM ───────→ Drupal Commerce ←────── ERP │ ├──── Payment Provider │ ├──── Shipping Provider │ └──── Accounting ``` Debemos identificar: - ERP - CRM - PIM - DAM - Accounting - Payment providers - Shipping providers - Marketplaces - Analytics - Marketing platforms Para cada integración deberíamos determinar también quién es propietario de cada dato. Por ejemplo: ```plaintext Producto → PIM Precio → ERP Stock → ERP Contenido SEO → Drupal Pedido → Commerce Factura → ERP Customer Lead → CRM ``` Esta definición de **Source of Truth** evita muchos problemas posteriores de sincronización. --- ## 16. Modelar el flujo comercial completo Una vez recopilada la información anterior deberíamos ser capaces de dibujar el proceso completo. Por ejemplo: ```plaintext Cliente ↓ Catálogo ↓ Producto ↓ Variación ↓ Precio ↓ Carrito ↓ Promoción ↓ Checkout ├── Datos del cliente ├── Dirección ├── Impuestos ├── Envío └── Pago ↓ Pedido ↓ ERP / Warehouse ↓ Fulfillment ↓ Cliente ``` Si todavía no podemos explicar claramente este flujo, probablemente todavía no estamos preparados para comenzar la configuración técnica. --- ## 17. Del modelo de negocio a Drupal Commerce Una vez entendido el negocio podemos comenzar a traducir los conceptos comerciales a Drupal Commerce. ```plaintext CONCEPTO DEL NEGOCIO ↓ ──────────────────────── DRUPAL COMMERCE ──────────────────────── ↓ Store Product Type Product Product Variation Type Product Variation Attributes Price Order Type Order Item Type Checkout Flow Payment Gateway Promotion Tax Type Shipping Method Order Workflow ``` La diferencia es importante. No comenzamos preguntando: > ¿Qué Product Types debemos crear? Sino: > ¿Qué productos comercializa realmente el negocio y qué diferencias comerciales existen entre ellos? Y solamente después decidimos cómo representarlos dentro de Drupal Commerce. --- ## 18. Checklist inicial de Commerce Discovery Antes de comenzar una configuración deberíamos ser capaces de responder, al menos a alto nivel, las siguientes preguntas: ### Negocio - ¿Qué vendemos? - ¿A quién vendemos? - ¿Dónde vendemos? ### Productos - ¿Qué constituye un producto? - ¿Qué constituye una variación? - ¿Qué atributos modifican lo que se compra? ### Precios - ¿Cómo se determina el precio? - ¿Hay diferentes monedas? - ¿Hay diferentes listas de precios? ### Clientes - ¿Existen diferentes tipos de cliente? - ¿Tienen condiciones comerciales diferentes? ### Impuestos - ¿Qué impuestos se aplican? - ¿Dónde se aplican? ### Promociones - ¿Qué descuentos necesitamos? - ¿Qué condiciones los activan? ### Checkout - ¿Qué información necesitamos? - ¿Qué pasos debe seguir el comprador? ### Pagos - ¿Cómo paga el cliente? - ¿Cuándo se realiza el cobro? ### Shipping - ¿Cómo se entregan los productos? - ¿Cómo se calcula el costo? ### Orders - ¿Qué estados tiene un pedido? - ¿Qué ocurre después de realizarlo? ### Integraciones - ¿Existe ERP? - ¿Existe CRM? - ¿Existe PIM? - ¿Quién es la fuente principal de cada dato? --- ## Conclusión Drupal Commerce es suficientemente flexible como para representar modelos de negocio muy diferentes. Precisamente por esa flexibilidad, una buena implementación depende de comprender primero el negocio y solamente después decidir cómo representarlo técnicamente. El proceso puede resumirse así: ```plaintext Entender qué vendemos ↓ Entender cómo se vende ↓ Entender quién compra ↓ Entender precios e impuestos ↓ Entender checkout y pagos ↓ Entender shipping y fulfillment ↓ Entender pedidos e integraciones ↓ Modelar el negocio ↓ Diseñar Drupal Commerce ↓ Configurar ``` En el siguiente artículo podremos comenzar el paso siguiente: **traducir este modelo comercial a la arquitectura de Drupal Commerce**, entendiendo cómo se relacionan Stores, Product Types, Products, Product Variations, Attributes, Order Types y Order Items antes de empezar a configurar nuestra primera tienda. ## Course navigation: Drupal Commerce Chapter 2 of 11 - [ ← Anterior Antes de configurar Drupal: Discovery y planificación de un proyecto ](/es/antes-de-configurar-drupal-discovery-y-planificacion-de-un-proyecto) - [ Siguiente → Arquitectura de Drupal Commerce: Stores, Products, Variations, Orders y sus relaciones ](/es/arquitectura-de-drupal-commerce-stores-products-variations-orders-y-sus-relaciones) [↑ Course index](/es/node/43)