Tres escenarios reales y cómo los resolvemos en producción.
Caso uno: sobreventa. El cliente reporta que vendió cinco unidades de un SKU y solo tenía tres. ¿Cómo pasó si tenemos stock de seguridad y stopper? Investigación típica: el marketplace tardó más de lo normal en aplicar el update a cero. AutoAzur reportó cero, el marketplace siguió mostrando stock viejo por minutos adicionales, y en esa ventana entraron pedidos extra. La mitigación de fondo: AutoAzur está implementando un logger que confirma del lado del marketplace que el cambio se aplicó —no solo que se envió. Mientras tanto, para SKUs de alta rotación, subimos el umbral del stock de seguridad.
Caso dos: pedido atorado en borrador. Llegó hace dos horas y sigue en draft. Tres causas comunes: el status del marketplace es "CANCELADO" y la automatización ya lo procesó —el pedido nunca debía confirmarse. El tipo de venta quedó en "Por definir" porque el código de canal no se detectó —arreglo: asignar el tipo manualmente. O el cron de confirmación está retrasado —arreglo: ejecutar el cron a mano y revisar por qué se quedó atrás.
Caso tres: stock que no se publica como esperas. El cliente dice "tengo 50 piezas, MercadoLibre muestra 30". Investigación: el cálculo es disponibles menos comprometidos. Si hay 20 piezas en pickings confirmados sin surtir, el sistema te quita esos 20. Es correcto: si los publicaras los venderías dos veces. La pregunta real es ¿por qué hay 20 pickings sin surtir? Y eso ya es operativo, no del plugin.
Lo importante: estos casos tienen huella en los logs. Siempre hay evidencia, siempre hay timeline. El soporte es auditable, no adivinanza.
1) ¿El cron está corriendo? · 2) ¿Hay logs del producto/pedido en las últimas N horas? · 3) ¿El status del marketplace coincide con lo que ve Odoo? · 4) ¿Hay pickings reservando inventario invisible?