«Les comandes d'Amazon entren soles a Odoo.» Entren, sí. La pregunta útil és una altra: entren amb tot el que cal per preparar, facturar i quadrar? Perquè el que es trenca no és la connexió (això es veu de seguida), sinó el mapatge. Una comanda mal importada no dona error: dona un albarà duplicat a l'octubre i un IVA que no quadra al gener.
Què porta una comanda d'Amazon, i què no porta encara
La capçalera porta l'identificador de la comanda, la data de compra, l'estat, el canal (FBA o FBM), el mercat en què es va vendre i la data límit d'enviament. Les línies vénen a part, amb l'ASIN, el teu SKU de venedor, la quantitat, el preu, l'impost i l'import d'enviament per separat, més els descomptes promocionals. I hi ha un moment en què una comanda existeix però encara no té res d'útil: mentre el pagament no està autoritzat, la comanda apareix pendent, amb línies sense preus ni impostos i sense adreça aprofitable. Si la teva importació la crea en aquest instant, crea una comanda a mitges que després ningú sap reparar.
L'identificador mana: sense ell, duplicats
Cada comanda arriba amb el seu identificador d'Amazon. Aquest número ha de quedar guardat a la comanda d'Odoo i ser el primer que es consulta abans de crear res. Si la importació crea primer i comprova després, qualsevol reintent (una caiguda de xarxa a mig cicle, un cron que se solapa amb l'anterior, una sincronització llançada a mà mentre corria l'automàtica) et deixa dues comandes idèntiques i dos albarans. Guarda també l'identificador de cada línia: és el que permet reconèixer una línia modificada sense esborrar i tornar a crear la comanda sencera.
Un detall que sembla menor i no ho és: la comprovació ha de recolzar-se en un índex únic a la base de dades, no només en una cerca prèvia en Python. Dos processos que corren alhora poden passar la cerca tots dos i crear tots dos. És un dels errors que més veiem en auditar connectors que va fer un altre.
Adreces: arriben restringides i cal esborrar-les
Les dades del comprador no vénen en la lectura normal de la comanda. L'adreça d'enviament i el contacte es demanen a part, amb una autorització específica per a dades restringides, i el correu que et donen és un àlies d'Amazon que deixa de funcionar. A més, hi ha l'obligació de no conservar-les: passat el termini que marca la política de protecció de dades d'Amazon, les dades personals s'esborren, i només es guarda el que la normativa fiscal obliga a conservar. A Odoo això té dues conseqüències pràctiques: crear un contacte permanent per cada comprador no sempre és bona idea, i cal un mecanisme de purga que algú hagi dissenyat a propòsit, no un oblit.
Impostos: en molts casos no els recaptes tu
En força mercats és Amazon qui reté i ingressa l'impost de la venda, i les línies de la comanda poden indicar qui és el responsable de fer-ho. Si la teva importació aplica sempre el mateix impost sense mirar aquesta dada, la comptabilitat surt malament en les dues direccions possibles: declarant de més o de menys. El que cal muntar abans de la primera comanda és una posició fiscal per país de destinació, una tarifa per divisa i una regla clara per al cas en què el responsable és Amazon. El detall per país és a vendre en diversos Amazon amb un sol Odoo.
Cancel·lacions: llegir només comandes noves no n'hi ha prou
Una comanda es pot cancel·lar mentre estava pendent, i llavors mai no va arribar a ser una comanda de debò. I es pot cancel·lar després d'haver entrat a Odoo i abans de sortir del magatzem: si la sincronització només sap crear, la cancel·lació no arriba i acabes enviant mercaderia que ningú pagarà. La importació ha de rellegir les comandes ja conegudes dins d'una finestra de temps, ordenant per data de l'última modificació, no només demanar les noves. I si l'albarà ja està validat, allò ja no és cancel·lar: és retornar, i es comptabilitza com a devolució.
Què fa el nostre connector
El connector d'Amazon per a Odoo resol l'entrada de comandes a Odoo 17, 18, 19 i 20: no crea la comanda de venda mentre Amazon la té pendent, guarda l'identificador d'Amazon amb una restricció única per compte i reutilitza la comanda de venda que ja existeixi en lloc de duplicar-la, conserva l'identificador de cada línia, demana l'adreça d'enviament en una crida a part i rellegeix les comandes per data de l'última modificació, de manera que els canvis d'estat, cancel·lacions incloses, es reflecteixen a la comanda de venda. Amb els impostos no decideix per tu: per defecte la comanda entra sense impostos i, si actives la facturació des d'Odoo, aplica els del producte a través de la posició fiscal que configuris. Si el que tens és un connector que ja falla, el diagnòstic és a errors freqüents de SP-API amb Odoo, i de vegades la resposta correcta és arreglar el que hi ha, no comprar-ne un altre.
Preguntes freqüents
Cada quant convé importar les comandes?
Diverses vegades per hora és raonable, però demanant per data de l'última modificació, no l'historial sencer cada vegada. L'API d'Amazon té límits de taxa i un cicle que demana de més es queda sense quota just quan hi ha pic de vendes.
Puc importar comandes antigues?
Sí, amb una càrrega inicial acotada per dates. Si ja tens comandes creades a mà, escriu-hi l'identificador d'Amazon abans d'encendre la sincronització: si no, el primer cicle les torna a crear.
I les comandes d'Amazon Business?
Vénen marcades com a tals i porten expectativa de factura amb les dades fiscals del comprador. Convé separar-les des del primer dia, perquè tractar-les com una comanda de particular obliga a refer factures després.
Enllaços útils dins de FlexigoTech
Què fem sobre això
Les comandes entren, però no quadren?
Explica'ns en quins mercats vens, si és FBA, FBM o tots dos, i què és el que no et quadra: duplicats, impostos o cancel·lacions. Mirem el mapatge abans de proposar res. Escriu a comercial@flexigobe.com o agenda una trucada.

