Integrar Amazon Seller Central con Odoo suena simple al principio: obtener los pedidos de Amazon y crear pedidos de venta coincidentes en Odoo. El enfoque habitual es ejecutar un trabajo programado cada pocos minutos y preguntar Amazon por nuevos pedidos.
Eso funciona, pero quería algo más inmediato.
En lugar de sondear continuamente a Amazon, utilicé el API de Notificaciones de Amazon Selling Partner, Amazon SQS y AWS Lambda. El resultado es una integración impulsada por eventos donde Amazon nos informa que algo ha cambiado, y Odoo reacciona a ese evento.
El flujo básico se ve así:
Amazon Seller Central → SP-API ORDER_CHANGE → Amazon SQS → AWS Lambda → Odoo → SP-API Orders API
Recibiendo notificaciones de pedidos de Amazon
La primera parte de la integración es una cola estándar de SQS.
Usando la API de Notificaciones de SP-API, la aplicación crea un destino que apunta a esta cola y se suscribe al ORDER_CHANGE tipo de notificación.
Amazon luego publica mensajes cada vez que hay un cambio importante en un pedido, como un cambio de estado del pedido o una cancelación solicitada por el comprador. Esto elimina la necesidad de sondear continuamente la API de Pedidos.
Una notificación típica contiene el ID del pedido de Amazon junto con información como:
{ "Payload":{
"OrderChangeNotification":
{ "AmazonOrderId":"123-1234567-1234567",
"OrderChangeType":"OrderStatusChange",
"Resumen":{
"EstadoDelPedido": "NoEnviado"
}
}
}
}Para mi integración, SQS está conectado a una función de AWS Lambda.
Usando Lambda como el puente a Odoo
La función Lambda es intencionalmente pequeña. No intenta crear el pedido completo de Odoo por sí misma.
Su trabajo es simplemente:
Leer el mensaje de SQS.
Analizar la notificación de Amazon.
Obtener el AmazonOrderId.
Decidir si el estado es relevante.
Enviar el ID del pedido a Odoo.
Conceptualmente, la parte importante es:
notificación = payload["OrderChangeNotification"]
si (
notificación["OrderChangeType"] == "OrderStatusChange"
y notificación["Resumen"]["EstadoDelPedido"] == "NoEnviado"
):
order_id = notificación["AmazonOrderId"]
# Enviar order_id a Odoo
Prefiero este diseño porque AWS solo maneja el transporte de notificaciones. La lógica de negocio real permanece dentro de Odoo, donde los productos, impuestos, almacenes, facturas y stock ya existen.
También vale la pena separar los estados de Amazon. Una NoEnviado notificación puede crear el pedido de venta, mientras que una Enviado notificación posterior puede actualizar el pedido existente y validar la delivery relacionada.
Creando el pedido dentro de Odoo
El módulo personalizado de Odoo expone un endpoint que recibe el ID del pedido de Amazon.
Por ejemplo:
POST /web/binary/create_amzn_sale_order
con:
{
"order_id": "123-1234567-1234567"
}
Odoo luego toma el control.
El endpoint primero verifica si existe un pedido con el mismo ID de pedido de Amazon. Si es así, evita crear otro.
Si el pedido es nuevo, Odoo obtiene un token de acceso LWA usando el token de actualización de Amazon y llama a la API de pedidos SP-API para recuperar la información completa del pedido.
A partir de ahí, el endpoint maneja la lógica de negocio normal de Odoo.
Determina si el pedido es FBA o FBM y selecciona el almacén correspondiente. Encuentra la moneda correcta y la lista de precios, crea el pedido de venta, empareja los productos de Amazon con los productos de Odoo, calcula el impuesto de mercado aplicable y crea las líneas del pedido de venta.
El endpoint también almacena información específica de Amazon directamente en el pedido de venta de Odoo, incluyendo el ID de pedido de Amazon, mercado, país, canal de ventas, canal de cumplimiento y estado del pedido de Amazon.
Una parte útil de la implementación es el manejo de retroceso. Si un ASIN de Amazon no puede ser emparejado con un producto de Odoo, se utiliza un Producto No Encontrado y el pedido se marca para revisión en lugar de simplemente fallar.
Manejar duplicados es importante
Una integración impulsada por eventos también necesita asumir que el mismo evento puede llegar más de una vez.
Amazon utiliza colas estándar SQS para este flujo de trabajo, y las colas estándar pueden ocasionalmente entregar notificaciones duplicadas o entregar eventos fuera de orden. Por lo tanto, Amazon recomienda diseñar el consumidor para tolerar mensajes duplicados.
Verificando AmazonOrderId before creating an Odoo order is a good first layer. In production I would go further and store Amazon’s NotificationId as well as enforce a unique database constraint on the Amazon order ID.
Yo también configuraría una cola de mensajes de SQS para que un pedido problemático pueda ser investigado sin bloquear el flujo normal.
Resultado final
Lo bueno de esta arquitectura es que cada componente tiene una responsabilidad muy pequeña.
Amazon detecta el cambio. SQS proporciona un buffer confiable. Lambda convierte la notificación en una solicitud simple. Odoo realiza el trabajo real de ERP.
No hay un trabajo cron revisando Amazon cada pocos minutos y no hay sondeos innecesarios cuando no ha sucedido nada.
Para mí, esa es la principal ventaja de usar la API de Notificaciones SP-API: Amazon se convierte en el disparador, mientras que Odoo sigue siendo el sistema donde se controla el proceso empresarial.
Convierte un trabajo de sincronización tradicional de Amazon a ERP en una integración mucho más limpia, casi en tiempo real.