Un pedido de Amazon no se cierra cuando el paquete sale del almacén: se cierra cuando Amazon recibe la confirmación de envío con su transportista y su número de seguimiento. Hasta entonces el pedido sigue pendiente para Amazon, aunque la mercancía ya esté en reparto. Ese aviso es una llamada a la API, y la hace tu ERP o una persona copiando números a mano.
El plazo lo pone Amazon, y es uno por pedido
Cada pedido llega con su fecha límite de envío. No es una recomendación ni un objetivo interno: es el compromiso que Amazon le ha dado al comprador en tu nombre. Esa fecha tiene que viajar del pedido al albarán de Odoo y ser visible para quien prepara, porque el orden que importa en el almacén es el de fechas límite, no el de llegada. Quien prepara por orden de entrada llega tarde a los pedidos urgentes y pronto a los que no corrían prisa.
Qué pasa cuando confirmas tarde
Amazon mide dos cosas distintas y las penaliza por separado: los envíos confirmados después de la fecha límite y los seguimientos que no puede rastrear. Los umbrales exactos los publica Amazon en el panel Estado de la cuenta de Seller Central y los revisa de vez en cuando, así que míralos ahí y no en un artículo. Lo estable es la consecuencia: la métrica se degrada, el comprador puede cancelar sin coste y, si la cosa se sostiene, se restringe la capacidad de vender.
En FBA el estado se lee; en FBM lo escribes tú
Es la confusión más habitual. Con FBA no confirmas nada: prepara y envía Amazon, y el número de seguimiento nace en su sistema, no en el tuyo. Lo que necesitas ahí es el camino inverso: traer ese estado a Odoo para que el albarán se cierre. Con FBM es al revés: el envío lo haces tú y el aviso lo das tú, dentro del plazo. Una operación mixta hace las dos cosas sobre el mismo catálogo, y cada pedido tiene que saber desde el primer momento de qué tipo es.
Si vendes con FBA, el estado de envío es solo una parte: el stock, las devoluciones y los reembolsos se mueven en el almacén de Amazon sin que tú los toques. Está desarrollado en Amazon FBA dentro de Odoo.
El código de transportista decide si el seguimiento cuenta
Amazon no acepta cualquier texto en el campo del transportista: tiene su propia lista de códigos y rastrea el envío contra el que le declares. Si mandas el número correcto con el transportista equivocado, o con un genérico tipo «otros», el seguimiento existe pero Amazon no puede seguirlo: a efectos de métrica, como si no lo hubieras mandado. Por eso la equivalencia entre tu transportista de Odoo y el código de Amazon tiene que ser una tabla explícita y editable, no una cadena escrita a mano dentro del código.
Dónde se juntan el conector de transporte y el de marketplace
El punto de encuentro es el albarán. La secuencia sana es ésta: el pedido entra con su referencia de Amazon y su fecha límite, se prepara, se valida el albarán, el conector del transportista pide la etiqueta y devuelve el número de seguimiento, y sólo entonces el conector de Amazon manda la confirmación con ese número y el código correcto. Si inviertes el orden, confirmas envíos que todavía no tienen etiqueta. Si no hay enlace entre los dos, alguien copia números a mano y ese alguien se equivoca un martes por la tarde.
El fallo que más encontramos al revisar integraciones ajenas está justo ahí: la confirmación se lanza en segundo plano, falla —error de la API, token caducado, el transportista tardó en dar el número— y nadie se entera, porque el albarán de Odoo ya está validado y en verde. La confirmación tiene que dejar rastro en el pedido: enviada, fallida, reintentada. Un trabajo que falla en silencio es peor que no tener integración, porque encima te da confianza.
Un pedido, dos paquetes
Los envíos parciales son el caso que casi nadie prepara. Si un pedido sale en dos expediciones, Amazon espera dos confirmaciones con sus líneas y sus cantidades, no una con el seguimiento del primer bulto. En Odoo eso son dos albaranes sobre el mismo pedido de venta, así que el mapeo tiene que ser por línea y no por pedido. Montarlo bien desde el principio cuesta poco; arreglarlo después de haber confirmado mal doscientos pedidos, no.
Cuándo hace falta automatizar esto y cuándo no
Si envías diez pedidos al día y confirmas a mano en Seller Central en cinco minutos, no necesitas una integración para esto: necesitas una rutina y un aviso. Automatizar sale a cuenta cuando copiar números ya es un trabajo, cuando hay varios transportistas en juego o cuando el mismo catálogo se vende en varios sitios y nadie sabe qué ha salido. Decirte lo contrario sería venderte algo que no te hace falta.
El conector de Amazon para Odoo cubre este carril: tabla de equivalencias de transportistas, confirmación por línea con número de seguimiento, estado del aviso y último error de Amazon en el propio albarán, reintentos automáticos y, en FBA, lectura del estado en lugar de escritura. Funciona en Odoo 17, 18 y 19. Los conectores de transportista están en el catálogo de módulos, y cómo se montan sin sorpresas, en etiquetas y seguimiento en Odoo.
Preguntas frecuentes
¿Cada cuánto avisa Odoo a Amazon de que el pedido ha salido?
En el momento de validar el albarán, y una tarea programada reintenta cada pocos minutos los que quedaron pendientes. Dejar los reintentos en una hora es arriesgado: esa hora se la come la fecha límite.
¿Puedo confirmar el envío sin número de seguimiento?
Amazon lo permite en algunos casos, pero ese envío cuenta como sin seguimiento válido y eso también se mide. Si el transportista da número, hay que mandarlo con su código.
¿Sirve si el conector del transportista lo hizo otro?
Sí, mientras deje el transportista y el número de seguimiento en el albarán. El enlace se hace ahí; no hace falta tocar el módulo del transportista.
Enlaces útiles dentro de FlexigoTech
Lo que hacemos sobre esto
¿Se te escapan los plazos de envío de Amazon?
Cuéntanos cuántos pedidos mueves al día, qué transportistas usas y si vendes con FBA, con FBM o con los dos. Miramos dónde se rompe la cadena antes de tocar nada. Escribe a comercial@flexigobe.com o agenda una llamada.