Desarrollador WooCommerce en Madrid

#WooCommerce para el Madrid que vende a empresas

Los proyectos WooCommerce que llegan desde Madrid no suelen ser la tienda de un artesano que vende cien referencias a particulares. Son distribuidores mayoristas de la zona de Vallecas y San Fernando de Henares con almacén propio y catálogos de miles de artículos, fabricantes que abren un canal digital para sus clientes de siempre sin renunciar al comercial de toda la vida, e importadores que sirven a la vez a la península y a mercados de América Latina. Ese perfil cambia por completo la conversación. La pregunta deja de ser cómo hacer un escaparate bonito y pasa a ser cómo hacer que WooCommerce se comporte como una pieza más del sistema de la empresa, hablando con el ERP, respetando el marco fiscal español y entendiendo que el cliente de empresa no compra igual que el consumidor.

WooCommerce llega a este terreno con una ventaja y una trampa. La ventaja es que, al ser WordPress por debajo, no impone un modelo de negocio cerrado: casi cualquier regla comercial, por rara que sea, se puede modelar con sus hooks sin pelearse contra la plataforma. La trampa es que esa misma flexibilidad, en manos de una instalación llena de plugins sueltos, produce tiendas que funcionan de milagro y se rompen en cada actualización. El trabajo de un desarrollador WooCommerce con criterio B2B es aprovechar lo primero sin caer en lo segundo.

#Catálogos de miles de SKU: lo que rompe las tiendas de plantilla

Una tienda de doscientos productos no revela los límites de nada. Los problemas aparecen cuando el catálogo mayorista real entra en la base de datos: varios miles de referencias, cada una con variantes de formato, color o medida, y a menudo con una unidad de venta distinta de la unidad de compra, porque el cliente pide cajas pero factura por unidad. En ese volumen, tres cosas empiezan a crujir a la vez. El panel de administración de productos se vuelve lento porque cada pantalla arrastra metadatos que nadie indexó. La búsqueda con filtros por atributo dispara consultas que ningún plugin de facetas resuelve solo. Y la actualización masiva de precios, la que se lanza cuando el proveedor cambia la tarifa, tumba el sitio si se ejecuta de forma ingenua.

Ninguno de esos problemas se arregla instalando otro plugin encima. Se arreglan en la capa que la mayoría de instalaciones ignora: indexación de la base de datos para las consultas que de verdad se ejecutan, importación de catálogo por lotes en segundo plano en lugar de una petición HTTP que agota el tiempo, y una estrategia de caché que distinga la página pública, que puede servirse cacheada, de la vista con precios de cliente, que no. Cuando un mayorista nos dice que su tienda actual va bien salvo los días de actualización de tarifa, casi siempre el diagnóstico está en esa capa y no en el tema.

#Precios por cliente, pedidos por CIF y compra de empresa

En B2B el precio no es una etiqueta, es un acuerdo. El mismo tornillo cuesta una cosa para el instalador que compra por palés y otra para el cliente ocasional, y esa diferencia no puede vivir en una hoja de cálculo aparte del sistema de venta. WooCommerce permite modelar esto bien si se hace desde el principio: tarifas por rol de cliente, tarifas específicas para cuentas concretas negociadas por el comercial, descuentos por volumen escalonados y la posibilidad de ocultar precios y el botón de compra hasta que la cuenta de empresa inicia sesión, algo que muchos mayoristas exigen porque no quieren enseñar sus condiciones a la competencia.

Alrededor del precio hay un flujo de compra que también es distinto. La cuenta se identifica por CIF, no por un correo cualquiera, y a menudo detrás hay varias personas: quien selecciona el material, quien aprueba el gasto y quien recibe la factura. Modelar cuentas de empresa con varios usuarios, roles internos y un circuito de aprobación de pedido convierte la tienda en una herramienta que el departamento de compras del cliente puede usar sin llamar por teléfono, que es exactamente el objetivo de digitalizar el canal mayorista. Todo esto se construye sobre los hooks documentados de WooCommerce y se registra, para que el mantenimiento no dependa de adivinar por qué un cliente ve un precio y otro ve otro.

#El ERP y el SII de la AEAT: donde está el proyecto de verdad

En la mayoría de estos encargos el escaparate es la parte visible y pequeña. El proyecto de verdad es la integración. Una empresa madrileña con almacén ya tiene un ERP donde vive la verdad del negocio: SAP Business One en las de tamaño medio, Sage 200 o a3ERP en buena parte del tejido industrial y de distribución. La tienda no puede ser una isla que duplique artículos, stock y clientes a mano. Definimos para cada dato en qué sistema manda y en qué dirección fluye: el artículo y su tarifa nacen normalmente en el ERP y bajan a la tienda, el stock se sincroniza según la frecuencia que el negocio tolere, y el pedido capturado en WooCommerce sube al ERP para convertirse en albarán y factura sin que nadie lo reteclee. Esa arquitectura, con sus casos de conflicto y su registro de errores, es la que decide si el proyecto ahorra trabajo o lo duplica. La tratamos como un servicio en sí mismo, descrito en detalle en nuestra página de integración de WooCommerce con ERP.

Sobre esa integración se apoya la obligación fiscal que más preguntas genera en Madrid: el Suministro Inmediato de Información. Las empresas que superan el umbral de facturación, están en el REDEME o forman parte de un grupo de IVA tienen que remitir el registro de sus facturas a la sede de la Agencia Tributaria en plazos muy cortos. La tentación del que no conoce el terreno es intentar que WordPress emita hacia el SII directamente. Es un error. La vía correcta pasa casi siempre por el ERP o por el software de facturación, que es donde reside la factura completa y donde ya existe la conexión homologada. Nuestro papel es que el pedido llegue a ese sistema con todos los datos que el SII necesita, no convertir la tienda en un emisor fiscal que nadie ha certificado. Con la entrada en vigor de la facturación electrónica obligatoria entre empresas y del reglamento de sistemas de facturación verificables, esta frontera importa más cada trimestre.

#IVA intracomunitario y exportación a América Latina

Una empresa madrileña que vende fuera de la península maneja dos regímenes fiscales que la tienda debe distinguir sin que el cliente tenga que pensar en ello. Para la venta a otra empresa de la Unión Europea con número de operador intracomunitario, la operación va sin IVA por inversión del sujeto pasivo, siempre que el número se valide contra el VIES, y esa venta luego se declara en el modelo 349. Configuramos la validación del VIES en el proceso de alta o de checkout y las clases de impuesto para que la exención se aplique sola cuando corresponde, no a golpe de código de descuento improvisado.

La exportación a América Latina es el otro caso, y es distinto de raíz. Un envío a México, Colombia o Chile sale de la Unión Europea, así que es una exportación exenta de IVA, con la contrapartida de la documentación aduanera y de los impuestos del país de destino, que corren por cuenta del comprador. La tienda tiene que reflejar bien esa exención según el destino y preparar el pedido para el circuito de aduana, y el comercial tiene que poder explicar al cliente latinoamericano por qué el precio no lleva IVA español pero sí tendrá aranceles allí. Modelamos las reglas de impuestos por zona y tipo de cliente para que este comportamiento sea correcto y auditable, porque un error sistemático de IVA en cientos de pedidos no es un detalle, es una regularización.

#Pasarelas para el mercado español: Redsys, Bizum y el pago B2B

El checkout dirigido a España tiene sus propias reglas no escritas. Para el cliente final, la vía natural es Redsys, porque es el sistema que hay detrás de los TPV virtuales de la mayoría de bancos españoles, y trabajar bien con él significa cubrir de verdad los flujos que importan: pago único, reembolso total y parcial, y la autenticación reforzada que exige la normativa de pagos. Bizum ha dejado de ser una curiosidad para convertirse en un método que buena parte de los compradores españoles espera encontrar, y omitirlo en una tienda B2C es dejar conversión sobre la mesa.

En B2B el pago cambia de naturaleza y esto se olvida a menudo. Una empresa que compra a otra rara vez paga con tarjeta un pedido de cierto tamaño: paga por transferencia, con pago aplazado a treinta o sesenta días, o contra una línea de crédito que el comercial le ha concedido. Un checkout mayorista serio ofrece la combinación adecuada a cada tipo de cuenta, no un único método pensado para el consumidor. Para tiendas que además quieren separar el escaparate del backend por rendimiento o por seguridad, la combinación de estas pasarelas con una arquitectura desacoplada tiene sus propias particularidades, que tratamos en la guía de WooCommerce headless para España con Bizum y Redsys.

#Rendimiento y seguridad cuando el checkout es el activo

El rendimiento de una tienda mayorista no se juega en la portada, se juega en las páginas de categoría con cientos de productos y en el checkout. Ahí es donde la caché mal entendida hace daño: cachear una página con precios de cliente sirve a un comprador el precio negociado de otro, un fallo que no es de velocidad sino de confidencialidad. Por eso la estrategia de caché se diseña por tipo de página y por estado de sesión, sirviendo cacheado lo público y dejando pasar al origen lo que depende del cliente identificado. El resto del trabajo de rendimiento es el habitual y aburrido que sí funciona: perfilar las consultas reales, retirar los plugins que cargan en cada página lo que solo usan en una, y controlar el peso de las imágenes de un catálogo que puede tener miles.

La seguridad, en una tienda que mueve datos de empresa y pagos, no es una capa que se añade al final. El checkout es la superficie que un atacante mira primero, así que el cumplimiento del estándar de la industria de tarjetas se garantiza delegando el dato sensible en la pasarela en vez de tocarlo, y el resto de la instalación se endurece por lo básico y efectivo: consultas parametrizadas, escapado de salida, verificación de nonces en cada formulario y limitación de intentos en el acceso. Un dato de empresa filtrado no es un incidente técnico menor cuando el cliente es otro negocio que confió su tarifa y sus condiciones a tu tienda.

#Tres puntos de partida en proyectos madrileños

El distribuidor con almacén y ERP: un mayorista de material técnico con varios miles de referencias vendía por teléfono y por correo, y su ERP ya llevaba años funcionando. El encargo no fue una tienda nueva sino un canal digital para sus clientes habituales, con las tarifas negociadas de cada uno visibles solo tras el login y el pedido volcándose al ERP para no reteclear nada. El escaparate fue lo rápido; lo que llevó tiempo fue acordar en qué sistema manda cada dato y qué hacer cuando el stock de la tienda y el del almacén discrepan.

La marca con canal B2B y B2C a la vez: un fabricante quería vender a sus distribuidores y también, en la misma web, directamente al consumidor, con precios, impuestos y métodos de pago distintos según quién mira. La clave fue no montar dos tiendas, sino una sola con dos comportamientos, separados por rol de cliente, de modo que la marca gestiona un catálogo y no dos. El consumidor ve precios con IVA y paga con Redsys o Bizum; el distribuidor ve neto, compra por volumen y paga a plazo.

El exportador a América Latina: una empresa que ya vendía en España abrió mercado en varios países latinoamericanos y descubrió que su tienda calculaba mal los impuestos en cada pedido de exportación. El trabajo consistió en modelar bien la exención de IVA por exportación fuera de la UE, preparar el pedido para la documentación aduanera y dar al equipo comercial una forma clara de explicar el precio al cliente de destino. No fue un rediseño, fue arreglar la lógica fiscal antes de que un volumen creciente de pedidos convirtiera el error en un problema serio.

#Cuándo no necesitas un desarrollador WooCommerce dedicado

Conviene decirlo, aunque aplace el proyecto. Si vendes un catálogo pequeño de productos sencillos a consumidores en España, sin tarifas negociadas, sin integración con un ERP y sin exportación, WooCommerce de serie con un buen tema y las pasarelas configuradas te lleva muy lejos por su cuenta. Encargar en ese caso un desarrollo a medida es pagar por complejidad que tu negocio no usa, y esa complejidad luego hay que mantenerla. Lo mismo ocurre cuando el problema real no es técnico: si las ventas flojean por el producto, el precio o la falta de tráfico, ninguna integración con el ERP lo cambia, solo entrega más rápido el mismo resultado.

El trabajo de un desarrollador dedicado empieza a compensar cuando aparece al menos una de las señales que definen el terreno B2B madrileño: un catálogo que por su volumen ya cruje, tarifas que dependen del cliente, un ERP que debe ser la única fuente de verdad, obligaciones de facturación como el SII, o ventas fuera de la península con la fiscalidad que arrastran. Si tu situación está en la primera categoría, te lo diremos en la auditoría y te ahorraremos el gasto. Si está en la segunda, ese gasto se paga solo en horas de administración que dejan de perderse.

#Alta como proveedor y encaje con vuestro ERP

Antes de tocar una línea de código, un proyecto WooCommerce mayorista pasa por el circuito de proveedores de tu empresa, y lo damos por hecho desde la primera reunión. Nos das de alta como proveedor externo, respondemos al cuestionario de seguridad y firmamos el acuerdo de tratamiento de datos que tu marco fiscal exige. Cuando el proyecto llega al ERP entramos a coordinar con quien lo mantiene, sea el partner de SAP Business One, el consultor de Sage 200 o el equipo interno que lleva a3ERP, porque una integración de stock y tarifas se pacta entre esos dos lados, no se impone desde la tienda. Facturamos de forma intracomunitaria como sociedad europea y el contrato es europeo, así que ese papeleo se resuelve una vez al principio y deja de estorbar el resto del proyecto. La cercanía que de verdad cuenta en una tienda mayorista no es compartir provincia con tu almacén, sino compartir idioma, coincidir en la jornada laboral y manejar el IVA, el SII y la aduana con los que factura tu negocio.

El proyecto avanza por etapas que se aceptan una a una. Primero la auditoría de catálogo, fiscalidad e integraciones, que termina con un plan y una estimación por fases en lugar de una tarifa cerrada sobre incógnitas. Después el diseño del modelo de datos y de precios, la integración con el ERP y la facturación, el QA de los caminos de pedido con pagos reales de prueba, y la puesta en producción con ruta de reversión. El presupuesto es individual y depende del volumen del catálogo, del número de integraciones y del régimen fiscal, no de una lista de tarifas. Y si tu base técnica de WordPress necesita manos antes de tocar la tienda, el desarrollo WordPress en Madrid es el punto de entrada; si lo que estás valorando es cambiar de plataforma o separar el frontend, la migración a Astro y Next.js en Madrid parte del mismo diagnóstico.

Última actualización: 10 de julio de 2026