Llega un cliente y te escribe: «He pedido la camiseta en talla L color rojo y mi factura solo dice ‘Pedido WC #1284’. ¿Esto qué es?». Y tiene razón: el cliente compró una variación concreta, y la factura legal no refleja ni la talla ni el color. Multiplica por cien pedidos al mes y entiendes por qué tu contable se enfada cuando le pasa el listado de ventas: no hay forma de saber qué se vendió. El problema no es WooCommerce, ni Factura Directa: es la integración entre los dos. Y la mayoría de soluciones que circulan por ahí —Zapier, plugins genéricos antiguos— pierden la información de variación por el camino.
El problema: variaciones woocommerce facturas que se pierden por el camino
Si vendes ropa, calzado, infusiones por sabor, móviles por capacidad o cualquier producto con opciones, las variaciones son la base de tu catálogo. WooCommerce las gestiona bien en la tienda: el cliente elige talla y color, ve el precio correcto y paga. El problema empieza después, cuando ese pedido tiene que convertirse en factura y demasiadas integraciones tratan el carrito como una caja negra.
Resultado típico: una factura con una línea genérica «Pedido WC #1284», o con el nombre del producto base («Camiseta Pro») sin pista de qué variación se compró.
Las consecuencias pegan a tres frentes.
El cliente reclama. Si compró talla L y le llega una M, la factura no le sirve para reclamar. Tu equipo de soporte tiene que ir al pedido en WooCommerce, cruzar datos y reconstruir qué fue qué.
El contable no entiende qué se vendió. Para análisis de ventas, márgenes por producto o cuadrar inventario con ventas, una línea «Pedido WC #1284» no aporta nada. Cuando hay 200 facturas así al mes, el listado es ilegible.
Hacienda te puede señalar. Las facturas legales exigen descripción suficiente del bien o servicio. «Pedido #1284» es ambiguo. En una inspección te puede tocar justificar producto a producto recopilando los pedidos originales de WooCommerce.
El usuario quiere lo obvio: que la factura en Factura Directa diga lo mismo que dice WooCommerce en el pedido. «Camiseta Pro – Talla: L, Color: Rojo – 1 x 39,90 €». Sin trampa.
Cómo gestiona WooCommerce las variaciones nativamente
Para entender por qué tantos integradores fallan, vale la pena recordar cómo guarda WooCommerce las variaciones.
Un producto variable es un producto padre con N variaciones hijas. La camiseta es el padre; cada combinación talla + color es una variación con su propio SKU, stock y precio.
Cuando un cliente compra una variación, WooCommerce crea un pedido con líneas (line items). Cada línea apunta al producto padre y a la variación concreta, e incluye un campo meta_data donde se guardan los atributos seleccionados con la convención attribute_<nombre>:
« attribute_pa_talla => "l" attribute_pa_color => "rojo" «
Si los atributos son globales (taxonomías), van con prefijo pa_. Si son personalizados del producto, van solo con attribute_<slug>. WooCommerce expone los nombres legibles («Talla», «Color») y los valores formateados («L», «Rojo») a través de la API REST.
La consecuencia práctica: la información de variación está disponible en el pedido, no se pierde. Lo que pasa es que recogerla y construir una descripción legible para una factura requiere recorrer ese meta_data y formatearlo. Y ahí es donde tropiezan las integraciones genéricas.
Por qué Zapier y plugins genéricos fallan con variaciones
Las dos vías más comunes para conectar WooCommerce con Factura Directa son Zapier (o Make) y plugins genéricos antiguos. Las dos suelen fallar con variaciones, por motivos distintos.
Zapier aplana el pedido. Cuando configuras un Zap del tipo «New Order in WooCommerce → Create Invoice in Factura Directa», lo que aparece en plantillas es un mapeo línea-única: número de pedido, total, cliente. Una factura con una sola línea «Pedido WC #1234» por todo el importe. Las variaciones no se ven por ningún lado.
Si quieres que cada línea del pedido sea una línea de la factura, en Zapier toca usar bucles (Looping by Zapier), parsear el array de line_items, sacar para cada uno producto + meta_data, formatear los atributos a «Talla: L, Color: Rojo» y mandarlo a la API de Factura Directa. Es factible, pero exige un nivel de Zapier que poca gente tiene, y Zapier cobra por step ejecutado: un pedido con cinco variaciones son cinco pasos.
Los plugins genéricos no leen attribute_*. Hay plugins de facturación para WooCommerce escritos hace años, no específicos de Factura Directa, que crean línea por producto pero ignoran el meta_data de variación. La factura tiene tantas líneas como productos, pero todas dicen «Camiseta Pro» sin distinguir entre L roja, M negra y XL blanca. Insuficiente.
Plugin oficial discontinuado. El plugin oficial gratuito de Factura Directa para WooCommerce ya no se mantiene, por lo que las opciones DIY decentes han mermado.
Encima se acumulan problemas adicionales en cuanto subes la complejidad: descuentos por cupón aplicados solo a una variación, productos en oferta, fees de pasarela, envío con IVA propio. Una integración que no entiende la estructura de WooCommerce te genera una factura que no cuadra con el pedido.
Cómo PayPam refleja talla, color y modelo en cada línea
PayPam ataca el caso desde el otro lado. En vez de partir de un mapeo Zapier-style «una línea por pedido», arranca por el meta_data de cada line item y lo construye explícitamente.
Cuando WooCommerce dispara el evento de pedido completado, PayPam recorre cada línea y:
- Lee el nombre del producto.
- Recorre el
meta_databuscando clavesattribute_*(sean globalespa_o personalizadas). - Resuelve el nombre legible del atributo y su valor formateado.
- Construye una descripción de línea con el patrón:
« Camiseta Pro – Talla: L, Color: Rojo «
Y monta la línea en Factura Directa con esa descripción, el precio unitario tal cual lo cobró WooCommerce, la cantidad y el IVA correspondiente. La estructura es exactamente la misma que ve el cliente en el «ver pedido» de WooCommerce.
Esto funciona con cualquier atributo. PayPam no tiene una lista cerrada de «talla, color, modelo»: detecta cualquier attribute_* presente en el line item. Si vendes infusiones por sabor, móviles por capacidad, sillas por material o vinos por añada y formato, todo entra en la descripción con el mismo patrón.
Compatibilidad con productos variables nativos y plugins de atributos
PayPam habla con la API estándar de WooCommerce. Soporta los productos variables nativos sin configuración extra y también lee atributos de plugins que extiendan el sistema de atributos, siempre que guarden los valores en el meta_data con la convención estándar (que es lo que casi todos hacen).
Casos cubiertos sin tocar nada: productos variables con dos o tres atributos, productos con decenas o centenares de variaciones, atributos personalizados a nivel de producto, atributos globales en taxonomías y valores con tildes en español.
Cantidad, precio unitario e IVA por línea
Cada variación va en su propia línea. Si alguien compra una camiseta L roja, una M negra y dos XL blancas, en la factura aparecen tres líneas con cantidades 1, 1 y 2. El precio unitario es el que pagó el cliente para esa variación concreta, no el del padre. El IVA es el del producto en WooCommerce.
Si tienes distintos tipos de IVA por producto (libros al 4%, ropa al 21%, alimentación al 10%), se respeta línea a línea como debe ir en una factura legal española. Para los matices de IVA en facturas automáticas, sirve la guía completa de Factura Directa.
Otros casos: descuentos, envío y fees por línea
La factura de un pedido WooCommerce real raramente es solo productos. Hay descuentos, envío, a veces fees de pasarela. Para que la factura cuadre con el cobro, todos esos elementos tienen que aparecer correctamente. PayPam los gestiona como líneas adicionales, no como ajustes ocultos al total.
Envío. Si el pedido tiene gastos de envío, PayPam añade una línea específica con su importe y el IVA que corresponda al método de envío.
Descuentos por cupón. Si el cliente aplicó un cupón, el descuento aparece reflejado. Cuando es porcentual sobre el total, se prorratea entre líneas. Cuando es de importe fijo o aplica solo a un producto, se refleja como tal. La factura cuadra con lo que cobró la pasarela, sin diferencias de céntimos.
Fees. WooCommerce permite añadir «fees» al pedido (envoltorio, pago contra reembolso, etc.). Aparecen también como líneas adicionales con su descripción e IVA.
El criterio es coherencia: la factura final tiene tantas líneas como conceptos cobrados, en el mismo orden y con los mismos importes que el pedido. Si necesitas el contexto global de plugins de NIF y facturación en WooCommerce, esta comparativa cubre los plugins relevantes y dónde encaja PayPam.
PayPam cuesta 7,95 €/mes en su plan plano, sin escalado por número de pedidos. Si haces 30 al mes o 3.000, el precio es el mismo. Esto importa frente a Zapier, donde un pedido con cinco variaciones puede consumir cinco tasks y los planes se disparan en cuanto vendes en serio.
Preguntas frecuentes
¿Funciona con cualquier nombre de atributo, no solo talla y color?
Sí. PayPam detecta cualquier clave attribute_* en el meta_data del line item de WooCommerce. El mecanismo es agnóstico al nombre concreto del atributo. Talla, color, modelo, sabor, capacidad, material, idioma, formato, cualquier atributo que tengas configurado en tu tienda aparece en la descripción de línea con el patrón «Atributo: valor».
¿Qué pasa si tengo decenas de variaciones por producto?
No hay límite efectivo. PayPam construye una línea por cada variación distinta presente en el pedido. Si en un mismo pedido un cliente compra una camiseta L roja, una M negra y una XL azul, la factura tiene tres líneas con su descripción, cantidad y precio unitario. Si el pedido lleva combinaciones más complejas (cinco productos con tres atributos cada uno, por ejemplo), el patrón sigue siendo el mismo: una línea por línea de pedido.
¿Y si uso un plugin que añade atributos personalizados?
Si el plugin guarda los valores en el meta_data del line item con la convención estándar attribute_*, PayPam los lee sin configuración. La mayoría de plugins de atributos extendidos (matrices, swatches, atributos visuales, etc.) respetan esa convención porque WooCommerce la usa internamente para mostrar los datos del pedido. Si tienes un caso muy específico donde el atributo se guarda en otro sitio, contacta con soporte para revisarlo.
¿Las variaciones afectan a la numeración o serie de la factura?
No. La numeración y la serie de la factura son del documento completo, no de las líneas. Cada pedido genera una factura con su número correlativo dentro de la serie que tengas configurada en Factura Directa. Las variaciones son solo descripciones de línea: estructuran la factura, no la numeran.
¿Puedo personalizar el formato de la descripción de línea?
El formato por defecto es Nombre del producto – Atributo1: valor1, Atributo2: valor2, que es el que recomendamos para que la factura sea claramente legible para cliente, contable y, llegado el caso, una inspección. Si tu caso requiere otro formato (incluir el SKU de la variación, separar atributos con guiones en vez de comas, añadir el código interno de producto, etc.), conviene revisarlo con soporte para ver si encaja con la operativa estándar o requiere un ajuste específico.
Cierra el círculo entre tu tienda y tu factura
Si tu catálogo de WooCommerce vive de variaciones y tu factura legal en Factura Directa no las refleja, tienes un problema de claridad que afecta al cliente, al contable y a tu propia trazabilidad de ventas. Zapier y los plugins genéricos suelen fallar aquí porque tratan el pedido como un total único o ignoran el meta_data de variación.
PayPam parte del nivel de detalle correcto: cada line item con sus atributos, cada línea con su descripción rica, cada factura con la misma información que ya muestra WooCommerce en el pedido. Sin Zapier, sin plantillas frágiles, sin «Pedido WC #1234».
Si vendes online en serio y quieres que tus facturas hablen con la misma claridad que tu tienda, pruébalo con la guía completa de Factura Directa y monta el flujo definitivo con tu primer pedido.