Un pedido de Temu no se cierra cuando lo preparas: se cierra cuando Temu sabe que lo has preparado. Hasta que el número de seguimiento no llega a su plataforma, para Temu ese pedido sigue pendiente, y el reloj que corre no es el tuyo. Ahí está toda la diferencia entre una integración que funciona y una que solo sabe importar pedidos.
El plazo lo trae cada pedido, no tu almacén
Temu asigna a cada pedido una fecha límite de expedición. No es una recomendación ni un objetivo interno de servicio: es un dato que viaja con el pedido (en la API de Temu, expectShipLatestTime) y es distinto para cada línea de tu cola de trabajo. Un almacén que prepara por orden de llegada incumple tarde o temprano, porque el orden de llegada y el orden de vencimiento no son el mismo orden. La regla es corta: si el plazo no está dentro de Odoo, no existe, y lo que no existe no se prioriza.
La fecha límite tiene que llegar hasta el albarán
Guardarla en el pedido de venta no basta. Quien prepara no mira pedidos de venta: mira albaranes. La fecha límite tiene que viajar del pedido al albarán, y estar en un campo por el que se pueda ordenar la lista, para que la vista de preparación se ordene por vencimiento y no por referencia. Es el mismo trabajo que contamos al importar los pedidos de Temu en Odoo: si el dato no entra en la importación, ningún automatismo posterior se lo puede inventar.
Confirmar el envío son dos datos, y los dos tienen que ser correctos
Temu no espera un «enviado»: espera un transportista y un número de seguimiento que su sistema pueda rastrear. Y el transportista tiene que identificarse con el código que Temu reconoce, no con el nombre que tú le hayas puesto al método de envío en Odoo. Un envío confirmado con un transportista que Temu no identifica es un envío que su plataforma no puede seguir, y acaba tratándose casi igual que si no lo hubieras confirmado. El número sale del transportista al generar la etiqueta; el trabajo de integración consiste en que ese número suba solo, en el momento en que se valida el albarán, y no cuando alguien se acuerde. Cómo se generan esas etiquetas está en etiquetas y seguimiento en Odoo.
Trampa clásica: los envíos multibulto. Si el albarán genera tres números de seguimiento y la confirmación solo sube el primero, el comprador ve un paquete y espera tres. Decide desde el principio qué número representa el envío y déjalo escrito.
Qué se penaliza realmente si se incumple
No es un recargo en la factura: es la cuenta. Un pedido expedido fuera de plazo cuenta como envío tardío, y esa métrica es la que Temu mira para decidir tu visibilidad y, si se repite, para aplicar restricciones. Un pedido sin seguimiento válido puede acabar cancelado, con la venta perdida y la mercancía ya en la calle. Los umbrales concretos están en tus condiciones de vendedor: no vamos a darte un porcentaje que no hemos medido. Lo que sí es constante es la dirección: se mide por pedido, se acumula por cuenta y se recupera despacio.
El fallo que nadie ve: la confirmación que no subió
El caso peligroso no es el error visible. Es la llamada que falla —la API no responde, el token ha caducado, el transportista no está mapeado— y nadie se entera, porque el albarán de Odoo se quedó validado igual. Dentro tienes el pedido servido; en Temu sigue pendiente y el plazo sigue corriendo. Una integración seria guarda el estado de la confirmación en el propio albarán, la vuelve a intentar y deja a la vista la cola de lo que no ha subido. Sin esa cola, el primer aviso llega por correo de Temu. Es el mismo patrón que describimos en cuando el tracking no llega a Amazon.
Qué hace nuestro conector, y cuándo no lo necesitas
Si envías cinco pedidos al día y nunca se te pasa uno, copiar el número en el panel de Temu sale más barato que cualquier integración: no nos contrates para eso. Empieza a compensar cuando hay varias personas preparando, varios transportistas o suficiente volumen como para que un pedido se pierda sin que nadie lo note. El conector de Temu para Odoo trae a Odoo la fecha límite de expedición de cada pedido, sube transportista y número de seguimiento al validar el albarán, traduce tus métodos de envío a los transportistas que Temu reconoce y guarda en el propio albarán el estado de cada confirmación (enviada, pendiente o con error, con el motivo), con un botón para reenviarla. La fecha límite queda en la ficha del pedido de Temu; ordenar por ella la lista de albaranes es un ajuste que hacemos a medida. Funciona en Odoo 17, 18 y 19, con migración a Odoo 20 el día que salga.
Preguntas frecuentes
¿En qué momento se sube el seguimiento?
Al validar el albarán, y otra vez si después se añade o cambia el número de seguimiento. Si la llamada falla, el albarán queda marcado con el error y se puede reenviar con un botón. Dejarlo en un cron de una hora regala una hora de un plazo que ya es justo.
¿Y si el número de seguimiento cambia después?
Se puede volver a enviar mientras Temu siga aceptando la modificación de ese pedido. Pasado ese punto la corrección deja de ser un asunto técnico y se convierte en una incidencia con atención al vendedor.
¿Funciona si es un operador logístico quien valida los albaranes?
Sí, siempre que el número de seguimiento acabe en el albarán de Odoo. Lo que cambia es de dónde sale: en vez de generarlo Odoo con la etiqueta, entra desde el operador. La confirmación hacia Temu es exactamente la misma.
Enlaces útiles dentro de FlexigoTech
Lo que hacemos sobre esto
¿Se te escapan plazos de Temu?
Cuéntanos cuántos pedidos mueves al día, con qué transportistas trabajas y quién valida los albaranes. Miramos si el problema es el plazo que no llega al almacén, el transportista mal traducido o confirmaciones que fallan en silencio. Escribe a comercial@flexigobe.com o agenda una llamada.