cómo sincronizar los pedidos de WooCommerce en un ERP sin volver a escribir

¿Por qué los pedidos de WooCommerce todavía se vuelven a escribir en el ERP

El departamento de finanzas todavía abre WooCommerce, copia el número de pedido en Comarch Optima, enova365 o Subiekt GT, y luego vuelve a escribir el NIP, la dirección de envío y cada línea. Esa rutina se rompe en el momento en que un cliente edita el método de envío después del pago, se realiza un reembolso parcial o un SKU de paquete en la tienda no existe como tarjeta en el ERP. El puente de hojas de cálculo que funcionaba con cincuenta pedidos al mes colapsa a unos pocos cientos: dos personas editan el mismo CSV, las tasas de IVA divergen y el almacén selecciona de un estado que la contabilidad nunca registró. El costo más profundo no es el tiempo de tipeo. Son las facturas disputadas, el stock que el ERP considera libre mientras la tienda ya lo vendió, y los cierres de fin de mes que esperan a que un humano concilie las comisiones de la pasarela de pago con la numeración de documentos. Las agencias que transfieren información a tiendas bajo NDA ven el mismo patrón repetidamente: la tienda es el frente comercial, el ERP es el libro legal, y no hay nada confiable entre ellos excepto el conocimiento tribal sobre qué campo personalizado significa qué almacén y qué método de pago se corresponde con qué caja registradora. Sin un contrato de automatización, también careces de idempotencia. Actualizar la página de agradecimiento o un reintento de webhook crea un segundo documento en el ERP para el mismo ID de WooCommerce. Luego, el personal anula los documentos a mano, lo que genera ruido en la auditoría y rompe las reglas de numeración secuencial que algunos contadores consideran sagradas. Las tiendas B2B multilingües lo empeoran: la empresa de facturación en el pedido es un grupo de IVA, el destino de envío es una sucursal, y el ERP espera ambos como contratistas vinculados antes de que se pueda registrar un pedido de venta. Los pedidos del marketplace enviados a WooCommerce agregan otro ID externo más que debe mantenerse correlacionado para que las devoluciones encuentren el documento fiscal correcto. Se acumulan casos límite de moneda e impuestos. Un pago en EUR contra una empresa en PLN en Optima necesita una fuente de tipo de cambio explícita y una fecha de contabilización. El IVA reducido en libros o alimentos en un lugar no debe volver silenciosamente a la tasa estándar porque la cadena de la clase de impuesto en WooCommerce fue renombrada durante una limpieza del tema. Envío como un servicio imponible separado frente al flete incluido en el total de la línea cambia cómo enova espera el esquema del documento. Las tarjetas de regalo, el crédito en tienda y las recargas de billetera a menudo nunca deben generar movimientos de stock, pero aún así necesitan un documento financiero o desaparecen de los informes de ingresos. Una solución duradera trata el pedido pagado de WooCommerce como un evento, asigna explícitamente los SKU y las clases de impuestos, genera un documento ERP por cada ID de pedido de la tienda, y refleja los cambios de estado para que el soporte nunca prometa un envío que el libro mayor no haya aceptado. Esa es la brecha que este caso de uso cierra: no un panel elegante, sino una transferencia confiable del carrito al documento contable con propiedad clara cuando falla la asignación y un camino de conciliación cuando se pierden webhooks durante la noche. Los manuales de operación deben nombrar a la persona que posee los mapas de impuestos de los SKU, la persona que limpia los pedidos en estado de error, y la vía de escalamiento cuando un período fiscal está cerrado en el ERP. Los simulacros de temporada alta que reproducen los pedidos pagados de ayer en una empresa de prueba en Optima o Enova detectan desajustes en la asignación antes de que afecten los números de documentos en vivo. Mantenga una matriz escrita de los métodos de pago para las cajas registradoras para que una nueva pasarela no registre silenciosamente en la caja equivocada.

cuando un pedido pagado de WooCommerce debería crear un documento ERP

Dispara en WooCommerce `order.paid` o `payment_complete`, y de nuevo en `order.updated` cuando la dirección de envío, los artículos de la línea o el estado cambien después de la primera escritura exitosa en ERP. También programa una reconciliación de quince minutos que liste los pedidos pagados que no tengan un ID de documento ERP en los metadatos del pedido, cubriendo fallos del webhook y pedidos creados por el administrador. No se active en `pending` o `on-hold` a menos que tu política reserve antes de la captura; la mayoría de los comerciantes de Polonia y DACH esperan el pago capturado para que Optima o enova no creen cuentas por cobrar que nunca se liquiden. Las renovaciones de suscripción deben usar el ID del pedido de renovación como clave de correlación, no solo el ID de la suscripción principal.

pasos para mapear los elementos de línea de WooCommerce en documentos de ventas de ERP

1. Validar el pedido: campos de facturación obligatorios, formato de NIP o VAT para B2B, moneda permitida por la empresa ERP, y que cada SKU de línea esté presente en la tabla de mapeo. Rechazar con un error estructurado si una línea de tarjeta de regalo o virtual no tiene artículo ERP y su política prohíbe omisiones silenciosas. Registrar la huella de validación para que reintentos idénticos se aceleren.
2. Inserte o actualice al contratista en el ERP. Coincida primero por NIP, luego por correo electrónico, y luego cree con la dirección de facturación. Adjunte la dirección de envío como dirección secundaria cuando los modelos Subiekt u Optima separan sucursales del comprador legal. Preserve el ID del cliente de WooCommerce como una clave externa para una deduplicación posterior.
3. Construya el documento de ventas: mapee las líneas de artículo, tasas de impuestos, envío como una línea de servicio o campo de flete, cupones como descuentos con el mismo tratamiento fiscal que usó la tienda, y el método de pago al código de caja o cuenta bancaria del ERP. Incluya las tarifas del mercado como líneas de costo solo cuando finanzas las solicite en el mismo documento.
4. Publique o guarde el documento según las reglas de la empresa, almacene el número de documento ERP y el ID interno en los metadatos del pedido de WooCommerce, y marque un estado de sincronización de `posted`, `draft` o `needs_mapping` para que el soporte pueda verlo sin abrir el ERP. Emita un evento interno para los oyentes del almacén o WMS.
5. En reembolsos o cancelaciones posteriores, cree la nota de crédito correspondiente o el documento de cancelación vinculado al ID original del ERP. Nunca invente un nuevo documento de ventas para un evento de reembolso. Devuelva el estado del documento del ERP a un estado de pedido personalizado o nota cuando se complete la contabilización en el almacén, incluyendo los cumplimientos parciales cuando el ERP los soporte.

cómo los webhooks de n8n y las API de ERP transportan la carga de pedidos

Prefiere los webhooks de WooCommerce hacia n8n para la transferencia casi en tiempo real, con Action Scheduler o WP-Cron como red de seguridad cuando el endpoint del webhook esté caído. n8n mantiene las tablas de mapeo, reintentos y la cola de mensajes fallidos; PHP personalizado directo está bien para una sola empresa Optima con SKUs estables, pero envejece mal cuando añades enova para una segunda entidad legal. La forma de la carga útil es JSON de pedido de tienda normalizado a un DTO interno: comprador, líneas, impuestos, pagos e IDs de correlación. El conector ERP luego se comunica con la API de Optima, los servicios web de enova, o un API de socio Subiekt o procedimiento SQL: elige un conector por código de empresa y nunca compartas tokens entre empresas. Los secretos viven fuera de la base de datos de WordPress en la bóveda del host de automatización. Los callbacks de estado del ERP, cuando están disponibles, solo actualizan la meta del pedido; no inventan nuevos pedidos de tienda. Google Sheets es aceptable como una vista de operador de fallas, no como el sistema de registro. Para alto volumen, procese por lotes el escaneo de conciliación, pero mantenga la ruta de pedido pagado un documento a la vez para preservar las claves de idempotencia. Documenta bases legales y consentimientos alineados con expectativas de la AEPD cuando el flujo toque datos personales.

qué hacer cuando el ERP rechaza una sincronización de pedido de WooCommerce

Clasificar fallos: validación (NIP incorrecto, SKU faltante), transporte (tiempo de espera agotado, 429) y rechazos comerciales (contratista bloqueado, período cerrado). Los errores de validación abren un ticket en Slack o por correo electrónico con el enlace del pedido y nunca se reintentan automáticamente hasta que se corrija el mapeo. Los errores de transporte se reintentan con retroceso exponencial y variabilidad hasta un número máximo, luego se envían a la cola de errores. Los rechazos comerciales congelan el pedido en `needs_erp_review` y notifican a finanzas; no seguir insistiendo en un período fiscal cerrado. Siempre escribir con clave usando el ID del pedido de WooCommerce para que los reintentos sigan siendo idempotentes. Registrar los hashes de solicitud y respuesta sin almacenar datos completos de la tarjeta ni el PESEL en bruto si aparece en campos personalizados. Si el ERP aceptó el documento pero la tienda no pudo guardar los metadatos, un trabajo de reconciliación debe detectar el huérfano buscando en el ERP por el ID externo en lugar de publicar nuevamente. Superficie un resumen semanal de la antigüedad de los mensajes muertos para que las colas silenciosas no se deterioren durante un mes.

cuando la entrada manual en el ERP sigue siendo más barata que la sincronización de pedidos

Con aproximadamente ochenta pedidos pagados al mes con una sola lista de SKU que nunca cambia, un empleado capacitado en Optima aún puede ser más barato que construir y supervisar conectores. También omita si el proyecto ERP está en migración y los esquemas de documentos cambian semanalmente: automatizará el caos. El dropshipping puro, donde el proveedor factura al cliente directamente, a menudo necesita un flujo de documentos diferente al de un pedido de venta clásico en Subiekt, así que no fuerce este patrón en ese modelo.

KPI que muestran que la sincronización de WooCommerce con ERP está en buen estado

• Minutos medianos desde payment_complete hasta el ID del documento ERP almacenado en la orden
• Porcentaje de pedidos pagados con más de una hora de antigüedad sin un ID de documento ERP
• Recuento de documentos ERP duplicados rastreados al mismo ID de pedido de WooCommerce por mes
• Proporción de intentos de sincronización que terminan en necesitas_mapeo frente a publicados