ERP para ecommerce: qué es, cómo elegirlo y aplicarlo
Contenido
- Índice
- El día a día de un vendedor que duplica trabajo en cada canal
- Qué es realmente un ERP para ecommerce y qué no lo es
- Los componentes clave que el ERP debe controlar en una tienda online
- Cómo se integra el ERP con tu tienda propia y con los marketplaces
- Criterios prácticos para elegir el ERP adecuado en el mercado español
- ROI real, beneficio por hora y cómo medir si el ERP está funcionando
- Checklist de migración e implementación sin sobresaltos
- Preguntas frecuentes
María vende complementos desde WooCommerce, Amazon y Mirakl. Cada mañana abre varias pestañas para comprobar qué queda disponible, descarga pedidos de cada canal y copia parte de la información en una hoja de cálculo antes de que el almacén empiece a preparar paquetes. Cuando termina, ha invertido horas en tareas que no aumentan las ventas y todavía no tiene la certeza de que el stock publicado coincida con el stock real.
El problema aparece cuando un mismo artículo tiene un SKU distinto en cada plataforma, una tarifa diferente según el canal o una actualización pendiente. Un pedido de Amazon puede quedarse fuera del flujo del almacén, una devolución puede no descontarse correctamente y un precio antiguo puede seguir visible en un marketplace. El resultado son ventas canceladas, errores de precio, mensajes de compradores y decisiones tomadas con datos incompletos.
En España, solo el 44% de las pymes utiliza software de gestión tipo ERP o CRM básico, mientras que el 31% vende online y el 28% usa software específico de su sector, según los datos recogidos por DesarrolloSoftware sobre la digitalización de las pymes españolas. La brecha explica por qué tantos negocios tienen presencia digital, pero siguen operando con herramientas separadas.
Un ERP para ecommerce bien integrado convierte el catálogo, el stock y los pedidos en una única operación. No elimina la necesidad de revisar excepciones, pero evita que el equipo tenga que reconstruir cada mañana la realidad del negocio a mano.
Índice
- El día a día de un vendedor que duplica trabajo en cada canal
- Qué es realmente un ERP para ecommerce y qué no lo es
- Los componentes clave que el ERP debe controlar en una tienda online
- Cómo se integra el ERP con tu tienda propia y con los marketplaces
- Criterios prácticos para elegir el ERP adecuado en el mercado español
- ROI real, beneficio por hora y cómo medir si el ERP está funcionando
- Checklist de migración e implementación sin sobresaltos
El día a día de un vendedor que duplica trabajo en cada canal
La rutina de María es común en negocios que han crecido añadiendo canales sin rediseñar la operativa. WooCommerce contiene una versión del catálogo, Amazon exige sus propios atributos, Mirakl aplica sus reglas de publicación y la hoja de cálculo intenta funcionar como inventario central. Ninguna de esas herramientas sabe por sí sola qué venta acaba de comprometer la última unidad disponible.
La primera avería suele estar en el identificador del producto. En la tienda aparece un SKU como BOLSO-NEGRO-M, Amazon utiliza un código interno diferente y el marketplace de terceros recibe una referencia recortada o duplicada. Si el mapeo no es exacto, el pedido entra, pero el sistema no sabe qué artículo debe reservar ni qué ficha debe retirar.
Dónde se rompe el flujo manual
La sincronización por lotes agrava el riesgo. Si una plataforma consulta el inventario con retraso, dos compradores pueden adquirir la misma unidad antes de que el segundo canal reciba el descuento. En catálogos con variantes, como tallas, colores o capacidades, el error no afecta solo al producto principal. Puede dejar disponible una combinación que ya se ha vendido.
El almacén también sufre la fragmentación. Un pedido puede quedarse en el panel del marketplace mientras el equipo prepara los pedidos de la tienda propia. Las devoluciones añaden otra capa de trabajo: alguien debe identificar el producto, comprobar su estado, actualizar el inventario y reflejar el movimiento en la contabilidad. Cuando nadie es responsable del ciclo completo, el dato acaba siendo distinto en cada sistema.
Regla operativa: si una persona tiene que copiar un pedido de una plataforma a otra para que el almacén pueda actuar, la integración ya está fallando.
Para un negocio que vende en varios canales, gestionar las ventas desde una aplicación multicanal puede reducir la dispersión, pero la decisión importante no es reunir pantallas. Es definir qué sistema manda sobre cada dato. El ERP debe actuar como fuente única de verdad para el stock disponible, las reservas, los pedidos y los movimientos que afectan al inventario.
Qué es realmente un ERP para ecommerce y qué no lo es
Un ERP para ecommerce es el sistema operativo de la actividad comercial. Recibe pedidos de la tienda propia y de los marketplaces, comprueba la disponibilidad, reserva unidades, actualiza estados, genera la información de facturación y deja trazabilidad de lo que ha ocurrido. El comprador solo ve la tienda o el marketplace. El equipo necesita ver la operación completa.
La analogía útil es la de un cerebro operativo. La tienda online presenta el producto y captura la compra. El marketplace aplica sus reglas de publicación y entrega la orden. El ERP decide cómo encaja esa orden con el catálogo, el inventario, el almacén, la factura y el envío.
ERP, CRM y conector no hacen el mismo trabajo
Un CRM organiza la relación con clientes y oportunidades. Guarda contactos, conversaciones, actividades comerciales y seguimientos. Puede indicar que un cliente ha comprado varias veces, pero no debería ser el responsable de reservar una unidad, gestionar una variante o conciliar un pago de marketplace.
Un conector básico mueve datos entre dos plataformas. Puede enviar un pedido a la tienda, copiar un precio o actualizar un campo. El problema es que muchos conectores no contienen reglas suficientes para resolver excepciones: reservas, pedidos pendientes de pago, devoluciones parciales, almacenes alternativos o márgenes mínimos por canal.
Un ERP aporta la lógica que falta entre ambos extremos. Puede decidir qué stock es vendible, qué almacén debe preparar un pedido, qué tarifa corresponde a cada canal y cuándo una devolución vuelve a estar disponible. La integración no consiste solo en transportar información. Consiste en transportar información validada y con una consecuencia operativa clara.
No todos los ERP encajan con una operación online
Un ERP diseñado para fabricación o distribución puede ser sólido en compras, contabilidad o planificación, pero insuficiente para un catálogo con combinaciones, atributos específicos por marketplace y tarifas comerciales diferentes. También puede requerir adaptaciones para la fiscalidad y los procesos habituales del ecommerce español.
Antes de valorar módulos, hay que comprobar si el sistema entiende:
- SKU y variantes, incluidos productos con talla, color, estado o configuración.
- Canales con reglas distintas, como Amazon, eBay, Mirakl o una tienda propia.
- Stock disponible, reservado y comprometido, no solo una cifra total.
- Estados de pedido, desde la autorización del pago hasta la devolución.
- Facturación y logística, con trazabilidad de cada movimiento.
La arquitectura mínima debe tocar pedidos, catálogo, precios, inventario, facturación, logística y reporting. Si una de esas piezas permanece en una hoja de cálculo, el equipo seguirá reconciliando datos manualmente aunque la demo del ERP parezca completa.
Los componentes clave que el ERP debe controlar en una tienda online
El ERP no se justifica por acumular módulos. Se justifica cuando controla los puntos donde una venta multicanal suele romperse. El orden importa: primero hay que asegurar la disponibilidad y el pedido, después automatizar precios, facturación y análisis.
Stock multi-almacén y reservas
El inventario debe distinguir entre unidades físicas, unidades reservadas, unidades en tránsito y unidades realmente disponibles para vender. Esa distinción es crítica si operas con varios almacenes, consignaciones o mercancía pendiente de revisión.
El ERP debe descontar la unidad cuando se confirma la operación según la regla definida, no cuando alguien recuerda actualizar una hoja. La integración con PrestaShop puede llegar a actualizar el stock desde el ERP en menos de 5 segundos en algunos desarrollos documentados por LabelGrup y su conexión entre PrestaShop y ERP. La velocidad exacta dependerá de la arquitectura, pero el principio es constante: cuanto más tiempo permanece un dato antiguo publicado, mayor es el riesgo de sobreventa.
Para profundizar en la parte operativa, conviene revisar cómo establecer un control de stock online con reglas claras. El ERP debe ser el origen de esa cifra y los canales deben consumirla.
Pedidos centralizados
El motor de pedidos reúne las órdenes de WooCommerce, PrestaShop, Amazon, eBay, Mirakl y otros canales en un flujo común. También debe admitir pedidos telefónicos o creados por el equipo, porque una operación real no vive exclusivamente en el checkout.
Un pedido que llega con pago pendiente no debería reservarse igual que uno confirmado. Un pedido dividido entre almacenes necesita otra regla. Una cancelación debe liberar la unidad y devolver el movimiento al inventario. Si el ERP no distingue esos estados, el equipo acaba corrigiendo consecuencias en lugar de gestionar excepciones.
Catálogo, EAN y atributos
El catálogo maestro necesita una referencia interna estable. A partir de ahí, el ERP debe mapear EAN, títulos, imágenes, descripciones, categorías y atributos según las exigencias de cada canal. Un producto puede tener una denominación comercial para la tienda y otra estructura de campos para Amazon o Mirakl, sin dejar de ser el mismo SKU.
Un catálogo sin EAN, atributos obligatorios o variantes bien relacionadas puede bloquear una publicación o crear fichas duplicadas. En productos usados, el reto es mayor porque el estado, las fotografías y la descripción pueden ser específicos de una unidad. No conviene forzar una estructura de producto nuevo sobre mercancía única.
Precios y reglas comerciales
El precio no es un campo aislado. Debe contemplar comisión del canal, coste de envío, promociones, impuestos, descuentos y margen mínimo. El ERP tiene que permitir tarifas por canal y reglas que impidan publicar un precio que convierta una venta en pérdida.
Facturación española
La facturación necesita series, impuestos, datos del comprador y trazabilidad de cada operación. El sistema debe adaptarse a las necesidades fiscales españolas y a los procesos B2B, además de distinguir operaciones nacionales e intracomunitarias cuando proceda. Una factura mal emitida no solo genera trabajo contable. Puede detener una conciliación o retrasar el cierre administrativo.
Logística y devoluciones
Picking, packing, transportista, seguimiento y devolución deben permanecer ligados al pedido original. La devolución tiene que indicar qué unidad vuelve, en qué estado y si se reincorpora al stock vendible. Las integraciones españolas con PrestaShop ya contemplan funciones como múltiples almacenes, combinaciones, imágenes y sincronización automática, como describe Sdi en su solución Prestasync.
| Componente | Función clave | Riesgo si falla |
|---|---|---|
| Stock multi-almacén | Reservar y publicar disponibilidad real | Sobreventas y cancelaciones |
| Pedidos | Centralizar órdenes y estados | Pedidos omitidos o duplicados |
| Catálogo | Mantener SKU, EAN y atributos coherentes | Listings bloqueados o duplicados |
| Precios | Aplicar tarifas, promociones y margen mínimo | Ventas con rentabilidad incorrecta |
| Facturación | Emitir documentos con reglas fiscales adecuadas | Incidencias contables y administrativas |
| Logística | Trazar preparación, envío y devolución | Pérdida de paquetes y stock no recuperado |
Cómo se integra el ERP con tu tienda propia y con los marketplaces
La tienda propia y los marketplaces no deben integrarse de la misma manera. WooCommerce o PrestaShop suelen permitir controlar mejor el catálogo, el checkout y la experiencia de cliente. Amazon, eBay, Mirakl o Cdiscount imponen formatos, estados, comisiones y políticas propias.
En la tienda propia, el ERP suele conectarse mediante API, módulo nativo o una capa intermedia. El flujo habitual envía catálogo, precio y disponibilidad desde el ERP hacia la tienda, mientras que los pedidos, clientes y datos de pago vuelven al sistema central. La prioridad es que la tienda no mantenga una copia independiente del stock.
En los marketplaces, la integración necesita más mapeo. Hay que relacionar SKU internos con referencias de cada cuenta, traducir estados, enviar atributos obligatorios y respetar las reglas de envío. Un PIM o un conector especializado puede ayudar con el catálogo, pero no sustituye la decisión de dónde se reserva el inventario ni cómo se resuelve una devolución.
El flujo correcto de datos
El ERP debe publicar el stock vendible y recibir las órdenes para validarlas. El marketplace no debería convertirse en la fuente de verdad solo porque sea el canal con más volumen. Cuando cada plataforma calcula su propia disponibilidad, el equipo pierde la capacidad de explicar por qué una unidad aparece disponible en un sitio y agotada en otro.
La arquitectura más fiable sigue esta secuencia:
- El ERP calcula disponibilidad por SKU y almacén.
- Cada canal recibe la cantidad publicable según sus reglas.
- El pedido entra en el ERP con su estado de pago.
- El ERP reserva la unidad y devuelve la actualización al resto de canales.
- El almacén prepara el pedido y transmite el estado de envío.
- La devolución modifica el inventario según la inspección recibida.
La sincronización puede ser bidireccional, pero no todos los datos deben viajar en ambas direcciones. El canal puede enviar una orden o una cancelación. El ERP debe controlar el stock, el precio maestro y la identidad del producto.
Huecos que hay que probar antes de contratar
Los fallos más costosos aparecen en los casos que no se enseñan en una demostración. Hay que probar una compra simultánea, un pedido duplicado, una autorización de pago pendiente, una cancelación, una devolución parcial y una variante sin disponibilidad. También hay que revisar qué ocurre cuando una API responde tarde o un conector se queda sin conexión.
Para distribuir un catálogo entre canales como Wallapop, Vinted y eBay, la conexión de Shopify con marketplaces puede formar parte de la arquitectura, pero debe quedar claro qué sistema reserva, qué sistema publica y qué sistema contabiliza.
| Aspecto | Tienda propia, WooCommerce o PrestaShop | Marketplace, Amazon, eBay o Mirakl |
|---|---|---|
| Catálogo | Mayor control sobre atributos y contenido | Campos y categorías impuestos por el canal |
| Pedidos | Flujo configurable y checkout propio | Estados, pagos y políticas del marketplace |
| Stock | Publicación desde el ERP hacia la tienda | Publicación con reglas por cuenta o canal |
| Precio | Promociones y tarifas bajo control propio | Comisiones y condiciones específicas |
| Devoluciones | Política definida por el negocio | Procedimiento y plazos del marketplace |
| Riesgo principal | Copia de stock desactualizada | Latencia, mapeo incorrecto o pedidos duplicados |
Criterios prácticos para elegir el ERP adecuado en el mercado español
Una demo puede mostrar un catálogo bonito y una pantalla de pedidos impecable. Eso no demuestra que el ERP soporte una venta real con reserva, devolución, comisión, factura y conciliación. La selección debe empezar por los casos que más daño causan cuando fallan.
La API debe ser una condición de entrada
Busca una API REST documentada, webhooks y registros de errores accesibles. Si el proveedor no explica qué eventos envía, cómo se reintenta una operación fallida y qué límites aplica, la integración dependerá demasiado de trabajo manual.
También hay que pedir ejemplos de payloads y probar la creación de un SKU, la actualización de una variante y la recepción de una cancelación. Una API que funciona en una demo controlada puede quedarse corta cuando el negocio necesita procesar excepciones.
Fiscalidad, almacenes y soporte
El ERP debe contemplar series de facturación, IVA, recargo de equivalencia cuando corresponda, operaciones intracomunitarias y las obligaciones de información aplicables al negocio. También conviene comprobar la compatibilidad con VeriFactu y con SII si el perfil fiscal de la empresa lo exige. No basta con que el proveedor diga “cumplimos la normativa”. Hay que pedir el alcance concreto, la fecha de actualización y quién mantiene la localización.
El multi-almacén y el multi-canal deben formar parte del modelo de datos, no aparecer como un complemento improvisado. Pregunta si el sistema separa stock físico, reservado y disponible, y si permite definir reglas distintas para cada almacén.
El soporte también cuenta. Un equipo que responde en horario español, conoce el flujo de marketplaces y puede revisar logs vale más que una base de conocimiento extensa si una actualización de stock se detiene durante una campaña.
Coste total y prueba con datos reales
El precio de licencia es solo una parte del coste. Incluye consultoría, limpieza de catálogo, conectores, mantenimiento, formación, usuarios adicionales, almacenamiento y posibles desarrollos. Calcula el coste por pedido y por canal, no solo la cuota mensual.
Antes de firmar, importa una muestra real con SKU problemáticos, variantes, devoluciones y precios distintos. La prueba debe comprobar el recorrido completo, desde la publicación hasta la conciliación. Si el proveedor solo acepta datos perfectos, todavía no has probado el sistema que necesitas.
Estos criterios también sirven para comparar software para ecommerce orientado a la gestión multicanal, siempre que la evaluación se centre en los flujos reales y no en la cantidad de iconos de la presentación.
Los errores de selección suelen repetirse:
- Elegir por precio sin calcular la integración.
- Confundir un conector de publicación con un ERP operativo.
- Ignorar devoluciones y conciliación de pagos.
- No comprobar la exportación de datos y la salida del sistema.
- Firmar sin una prueba con el catálogo y los pedidos del negocio.
ROI real, beneficio por hora y cómo medir si el ERP está funcionando
El retorno del ERP no aparece en la lista de funcionalidades. Aparece en el tiempo que el equipo deja de dedicar a copiar pedidos, corregir stock y buscar facturas. También aparece en los errores que ya no llegan al comprador.
Empieza con una fotografía de la operación actual. Registra cuánto tiempo se dedica a introducir pedidos, actualizar disponibilidad, revisar precios, conciliar pagos, emitir facturas, tramitar devoluciones y preparar informes. Después separa las horas que el ERP puede automatizar de las que seguirán requiriendo criterio humano.
La fórmula práctica es sencilla:
Ahorro operativo = horas liberadas × coste interno por hora
Después resta la licencia, la integración, el soporte y el mantenimiento. El resultado no debe presentarse como una promesa de ventas. Es una estimación de capacidad recuperada y de errores evitados.
Qué debe mejorar primero
La primera señal no es que el equipo use más pantallas. Es que procesa más pedidos con menos intervención manual. La segunda es que el inventario deja de necesitar correcciones constantes. La tercera es que finanzas puede conciliar pedidos, cobros y facturas sin reconstruir la actividad desde varios paneles.
Mide los datos por canal y por SKU cuando sea posible. Un promedio global puede ocultar que Amazon funciona bien, pero la tienda propia acumula pedidos pendientes, o que una familia de variantes concentra todas las incidencias.
No atribuyas al ERP cualquier mejora comercial. Una campaña, un cambio de precio o una temporada de mayor demanda pueden alterar las ventas. El impacto operativo se demuestra mejor con tiempos de procesamiento, errores y calidad del dato.
Cuadro de control operativo
| KPI | Qué mide | Valor objetivo tras 90 días |
|---|---|---|
| Tiempo medio de procesado de pedido | Rapidez desde la recepción hasta la preparación | Descenso estable sin aumentar incidencias |
| Tasa de sobreventa por canal | Pedidos que no pueden servirse por disponibilidad incorrecta | Tendencia a cero y causas documentadas |
| Horas-hombre en tareas manuales | Trabajo dedicado a copiar, corregir y conciliar | Reducción visible frente a la línea base |
| Margen neto por SKU | Rentabilidad después de costes y comisiones | Datos completos para decidir compras y precios |
| Pedidos con excepción | Casos que requieren intervención del equipo | Menos casos y resolución más rápida |
| Diferencia entre ERP y almacén | Calidad del inventario registrado | Conciliaciones pequeñas y explicables |
Revisa los indicadores en ciclos regulares y asigna un responsable a cada desviación. Si el stock no coincide, hay que saber si falló el mapeo, la reserva, el webhook, la recepción de mercancía o la devolución. Sin causa, el KPI solo describe el problema.
Checklist de migración e implementación sin sobresaltos
Una implantación falla con más frecuencia por datos ambiguos que por falta de funcionalidades. El proyecto debe empezar antes de conectar la primera API, con un inventario claro de SKU, canales, almacenes, reglas de reserva y responsabilidades.
Auditoría previa
Documenta cómo entra un producto, dónde se almacena, cuándo se publica, qué ocurre cuando se vende y quién gestiona la devolución. Haz un mapa de WooCommerce o PrestaShop, Amazon, eBay, Mirakl, sistemas contables, transportistas y hojas de cálculo.
El entregable debe ser un mapa de sistemas y un diccionario de datos. Incluye la referencia interna, el identificador de cada canal, el almacén, la unidad de medida, el estado del pedido y la regla que define el stock vendible. Si dos sistemas creen ser propietarios del mismo campo, resuélvelo antes de migrar.
Limpieza de catálogo
Unifica SKU, EAN, títulos, unidades, atributos, variantes, fotografías y traducciones. Separa productos con identidad permanente de artículos únicos, especialmente en segunda mano. No fusiones referencias solo porque compartan una descripción parecida.
Entrega un catálogo maestro con incidencias registradas. Los duplicados, las variantes huérfanas y las fotografías asignadas al SKU equivocado suelen aparecer después del lanzamiento, cuando corregirlos ya afecta a pedidos activos.
Configuración del ERP
Define la jerarquía de almacenes, las reservas, las ubicaciones, las políticas de reposición y los estados de pedido. Conecta la contabilidad española y valida series, impuestos, clientes B2B, devoluciones y operaciones intracomunitarias.
Prueba qué ocurre cuando llega una unidad, se reserva para un pedido, se cancela y vuelve al stock. También establece quién puede modificar precios, liberar reservas o corregir inventario. El control de permisos evita que una corrección rápida borre la trazabilidad.
Integración técnica
Conecta primero los flujos esenciales: catálogo, stock y pedidos. Después añade precios, expediciones, facturación, devoluciones y reporting. Las APIs de WooCommerce y PrestaShop deben probarse con eventos reales, igual que los conectores de marketplaces.
No actives todos los canales a la vez sin una estrategia de reversión. Prepara colas de reintento, alertas de error y un registro que permita identificar el último dato recibido. Un sistema que falla de forma visible se puede operar. Uno que falla en silencio genera sobreventas.
Lanzamiento controlado
Mantén un periodo en paralelo y compara pedidos, stock, precios, impuestos y estados de envío. Haz una validación por SKU y por canal, no solo una revisión general del total. El cuadro de mando debe mostrar sobreventas, pedidos atascados, duplicados y diferencias entre el ERP y el almacén.
Antes de desactivar los sistemas antiguos, el equipo tiene que poder:
- Consultar el stock disponible y reservado.
- Encontrar un pedido por SKU, canal o cliente.
- Reprocesar una orden fallida.
- Registrar una devolución correctamente.
- Exportar datos y generar la información contable necesaria.
- Saber a quién escalar una incidencia.
El calendario dependerá del número de canales, almacenes, variantes y calidad del catálogo. Un negocio pequeño puede avanzar con una implantación contenida, mientras que una operación con varios marketplaces y reglas fiscales necesita más pruebas. No conviene fijar una fecha de salida sin haber completado la conciliación y la formación.
Revisa la integración de forma mensual después del lanzamiento. Las credenciales caducan, los marketplaces cambian campos, los transportistas modifican estados y el catálogo continúa creciendo. La auditoría periódica mantiene la fuente única de verdad como una práctica operativa, no como una configuración que se abandona el día de la puesta en marcha.
La transición se puede apoyar en una migración por olas: primero catálogo, después stock, luego pedidos y finalmente facturación y analítica. Cada ola debe tener un criterio de aceptación y un plan para volver al flujo anterior si aparece una diferencia sin explicar.
Un ERP para ecommerce no arregla un catálogo desordenado ni una regla de stock mal definida. Lo que hace es aplicar esas reglas de forma consistente en todos los canales. Si la empresa decide qué sistema manda, prueba los casos difíciles y mide el tiempo que recupera el equipo, la integración deja de ser un proyecto de software y se convierte en una mejora concreta de la operación.
Preguntas frecuentes
¿Qué diferencia hay entre un ERP, un CRM y un conector?
Un CRM organiza la relación con clientes y oportunidades. Un conector mueve datos entre dos plataformas, pero suele quedarse corto ante las excepciones. El ERP aporta la lógica que falta: decide qué stock es vendible, qué almacén prepara un pedido, qué tarifa corresponde a cada canal y cuándo una devolución vuelve a estar disponible.
¿Qué debe controlar como mínimo un ERP para ecommerce?
Pedidos, catálogo, precios, inventario, facturación, logística y reporting. Si una de esas piezas sigue en una hoja de cálculo, el equipo seguirá reconciliando datos a mano aunque la demo parezca completa.
¿Cómo se comprueba un ERP antes de contratarlo?
Pide una API documentada con webhooks y registros de errores, confirma el alcance fiscal concreto y calcula el coste por pedido y por canal. Después importa una muestra real con SKU problemáticos, variantes, devoluciones y precios distintos, y prueba el recorrido completo hasta la conciliación.
Ruit centraliza inventario, publicación multicanal, precios, pedidos, mensajería y analítica para negocios profesionales que venden en varios marketplaces, y puede conectarse con tiendas propias y sistemas ERP según el plan. Visita Ruit para comprobar si encaja con tu flujo actual y reducir el trabajo duplicado que provoca el stock desincronizado.
