Varias tiendas WooCommerce y un solo ERP: cómo coordinar catálogo, stock y pedidos
Abres una segunda tienda WooCommerce para una marca o una oferta profesional. Al coordinar varias tiendas WooCommerce, buena parte del Catálogo procede del mismo ERP, pero cada tienda tiene sus propios productos, Pedidos y decisiones comerciales.
Aunque ambas utilicen WooCommerce, compartir nombres o números no garantiza que una actualización llegue al lugar correcto. Vamos a seguir dos tiendas con una referencia común y un pedido cuyo número se repite para entender qué debe coordinarse.
Varias tiendas WooCommerce: multisite o instalaciones separadas
Puedes utilizar dos instalaciones WordPress o sitios de una red Multisite. Esa elección cambia la administración de la infraestructura, pero no define por sí sola una operación comercial compartida.
La documentación de WordPress Multisite explica que el contenido de los sitios conserva tablas propias y que la red comparte usuarios. Por tanto, una cuenta en la red no significa que catálogo, pedidos o condiciones de todos los sitios sean una única colección sincronizada.
En el escenario, «Marca» vende al público y «Profesional» atiende a empresas. Ambas reciben artículos del mismo ERP. La identidad de una operación necesita reconocer cuál de las dos participa, además del recurso de WooCommerce y el entorno.
La autenticación y permisos se configuran para el acceso que corresponda a cada destino. Compartir la red no autoriza a utilizar indistintamente las conexiones de ambos sitios.
El catálogo común puede tener varias vistas comerciales
Imagina una empresa con una tienda de consumidor y otra profesional. Algunas referencias se venden en ambas y otras pertenecen a un único canal.
El ERP puede conservar una identidad común del artículo. Cada WooCommerce utiliza sus propios identificadores, categorías y presentación.
La integración necesita relacionar esas representaciones sin exigir que todo el contenido sea idéntico.
Puedes mantener una descripción o selección propia de cada canal y actualizar desde el ERP los datos que correspondan. Las responsabilidades deben quedar claras para que una tarea de una tienda no sobrescriba contenido de otra.
Elige ejemplos comunes y exclusivos. Comprueba qué criterio determina su publicación y qué ocurre al retirar una referencia de una sola tienda.
Define cómo se reparte la disponibilidad
Si todas las tiendas utilizan el mismo almacén, sus ventas participan en una operación compartida.
Una cantidad publicada en tres sitios no crea tres veces esa mercancía. La política puede utilizar disponible común, asignaciones por canal o decisiones distintas según referencia.
Necesitamos conservar el efecto de cada venta y reconocer cuándo el ERP la ha incorporado. Durante el recorrido puede existir información con momentos diferentes.
La frecuencia de actualización ayuda a propagar cambios; la coordinación debe evitar recuperar cantidades anteriores o descontar dos veces una compra ya reflejada.
Conviene probar una referencia compartida y una operación en cada tienda. El equipo podrá comprobar qué efecto espera en las demás y qué información necesita para explicarlo.
Distillsync permite preparar consultas y transformaciones dentro de las tareas. El cálculo de disponibilidad debe corresponder a la política del canal y a los mecanismos compatibles del entorno.
Repartir unidades y compartir una bolsa producen ofertas distintas
Las dos tiendas del ejemplo utilizan diez TAZ-01 disponibles en el ERP y el negocio reserva dos como margen. Tiene ocho unidades para ofrecer al conjunto.
Una política reparte cinco a Marca y tres a Profesional. La suma de las ofertas respeta las ocho, pero una tienda puede agotar su cuota mientras la otra conserva unidades. Reasignar el reparto requiere otra decisión y su actualización correspondiente.
Otra política permite que ambas consulten una bolsa común. El resultado comercial es distinto: cualquier canal puede consumirla, y la coordinación debe reconocer las compras de todos antes de volver a ofrecer unidades. Publicar ocho en cada tienda sin aquel seguimiento expone la misma mercancía por duplicado.
Supongamos una compra de dos en Marca y una de uno en Profesional. La bolsa común conserva cinco para nuevas compras si los tres compromisos se cuentan una vez. Cuando el ERP ya refleja esas ventas, los ajustes transitorios deben dejar de descontarlas de nuevo.
La elección depende del servicio y de los mecanismos disponibles. Las actualizaciones periódicas, las cuotas y los márgenes tienen límites distintos; ninguno se convierte automáticamente en una garantía ante compras simultáneas.
Para revisar la operación guardamos la política elegida y una compra de cada tienda. El artículo compartido mantiene su referencia; los pedidos conservan sitio y origen. La calidad del dato en la integración también importa aquí: una cantidad necesita explicar qué compromisos y qué tiendas está representando.
Con ese significado, una diferencia puede revisarse desde el reparto o desde el recorrido de un pedido, en lugar de corregir a mano las dos tiendas cada vez que cambia el almacén.
El comprador puede tener relaciones distintas por canal
Una persona puede comprar a título particular en una tienda y para una empresa en otra. También puede haber varias cuentas que deben relacionarse con un mismo cliente comercial.
La integración necesita una política de identidad que refleje esa realidad.
Fusionar por correo de forma automática puede perder contexto. Crear siempre otra ficha también puede fragmentar condiciones e historial.
Conviene conservar correspondencias explícitas y alternativas definidas para nuevas cuentas. La dirección del pedido y los datos generales del cliente necesitan responsabilidades propias.
Si existen Precios profesionales, su asignación también debe respetar qué cuenta y qué tienda participan. El grupo o mecanismo de una instalación puede tener otra función en la siguiente.
El pedido 240 de una tienda no es el 240 de la otra
La referencia TAZ-01 aparece como producto 240 en Marca y como producto 240 en Profesional. También coinciden por casualidad los números internos de dos pedidos. Los valores son ficticios; ilustran una coincidencia que el contexto debe resolver.
| Operación | Origen completo del caso | Relación esperada en ERP |
|---|---|---|
| Venta al público | Marca, producción, pedido 240 | Documento de esa compra y su cuenta |
| Venta profesional | Profesional, producción, pedido 240 | Otro documento, con su cuenta y condiciones |
| Actualización de TAZ-01 | Marca, producto 240 | Actualizar el recurso de Marca |
| Actualización de TAZ-01 | Profesional, producto 240 | Actualizar el recurso de Profesional |
Buscar únicamente 240 mezcla identidades de recursos y tiendas. El seguimiento necesita conocer si hablamos de producto o pedido y a qué sitio pertenece.
Las dos fichas pueden mantener títulos comerciales distintos. El ERP aporta la referencia y los campos acordados; una actualización común dirige cada operación a su correspondencia, conservando lo que pertenece a cada tienda.
Esta representación desarrolla lo que explicamos sobre producto, variante y SKU: el identificador tiene un significado dentro de un contexto, incluso cuando la referencia comercial es compartida.
Un cambio compartido debe tener un alcance definido
El negocio puede actualizar una tarifa común, mientras cada equipo mantiene su contenido comercial. O puede cambiar el criterio de publicación de una sola tienda.
La configuración debe distinguir qué recorridos participan y qué condiciones se conservan en los demás.
También hay que reconocer las dependencias. Si una referencia todavía no existe en una tienda, actualizar su disponibilidad puede requerir un tratamiento distinto al de otra ya relacionada.
Para una agencia, describir ese alcance permite mantener varios canales sin depender de recordar excepciones invisibles. Cada cliente y tienda conserva una explicación de lo que comparte y de lo que controla por separado.
Consulta el módulo de Catálogo.
Copiar la tienda también copia datos que necesitan otro ámbito
Preparas una copia de Marca para probar un tema. El catálogo y los números de pedido siguen presentes, pero el entorno de prueba no debe participar como otro canal productivo sin una decisión expresa.
En el caso, las tareas de la copia no importan ventas reales ni actualizan disponibilidad de producción. Las conexiones y el ámbito se revisan antes de activar cualquier recorrido. Un pedido 240 de esa copia se distingue del 240 productivo, aunque tenga el mismo contenido.
Después añadimos una referencia a Profesional. La selección comercial de Marca la excluye. Esperamos que el alta aparezca únicamente donde corresponde; el uso de una fuente ERP común no obliga a publicar todo en ambos sitios.
Distillsync permite preparar selección y transformaciones mediante tareas. La guía WooCommerce–ERP sitúa el intercambio; con varias tiendas, cada operación necesita conservar el ámbito del sitio y del entorno al que pertenece.
Varias tiendas pueden compartir gestión y conservar identidad
Coordinar WooCommerce con un único ERP requiere saber qué datos pertenecen al negocio común y qué representación necesita cada canal.
Distillsync utiliza un modelo semántico común y tareas configurables para preparar ese intercambio. Puedes empezar con una muestra de cada tienda y comprobar su relación con la operación compartida.
El comprador utiliza su canal. La empresa puede continuar cada venta sabiendo de dónde procede y qué decisiones la acompañan.
Descubre Distillsync para WooCommerce o crea tu cuenta y empieza a probarlo.