En resum
- Tria un únic sistema mestre de l'estoc i fes que els canals rebin la xifra ja calculada.
- La sobrevenda neix en el buit entre una venda i l'actualització de la resta de canals.
- Un marge de seguretat per canal redueix el risc en productes amb poques unitats.
- Les comandes d'Amazon han d'entrar a l'ERP amb el seu canal i el seu identificador original.
Sincronitzar estoc amb Amazon sembla cosa d'un connector: instal·les una app, enllaces els productes per SKU i la xifra s'actualitza sola. Funciona mentre el catàleg és petit i les vendes van a poc a poc. Quan el mateix producte es ven alhora a la botiga, a Amazon i en altres marketplaces, comencen les sobrevendes i les comandes que arriben a l'ERP amb dades que no quadren. Aquesta guia explica com organitzar l'estoc compartit entre canals i què has de decidir abans de triar entre un connector i una integració pròpia.
Qui mana en l'estoc quan vens en diversos canals
El primer pas és decidir on viu la xifra d'estoc. Pot ser l'ERP, el programa de magatzem, la mateixa botiga o una eina intermèdia que reparteix l'inventari entre canals. El que dona problemes és que cada canal porti el seu propi número i es corregeixin els uns als altres.
Amb un sistema mestre, el recorregut de cada venda és sempre el mateix:
- Vendaentra una comanda en qualsevol canal
- Reservael mestre descompta les unitats de la comanda
- Recàlculestoc vendible menys el marge de seguretat
- Publicacióla nova xifra arriba a cada canal
- Comanda a l'ERPentra amb el seu canal i la seva referència
Si la botiga és Shopify i l'ERP porta el magatzem, a integrar Shopify amb un ERP sense desquadrar l'estoc expliquem com repartir els papers entre els dos sistemes.
Estoc vendible: la xifra que publiques a cada canal
L'estoc físic del magatzem gairebé mai no és el que convé publicar. A les unitats que hi ha a la prestatgeria cal restar-hi les reservades per a comandes cobrades que encara no han sortit, les que estan malmeses o pendents de revisar i, si ho decideixes així, un marge de seguretat. A la guia sobre l'estoc de Shopify i la venda en línia veiem per què tenir unitats no sempre vol dir poder vendre-les.
El marge de seguretat és una reserva per canal. Si queden tres unitats, la botiga pot continuar oferint-les totes mentre Amazon deixa de mostrar el producte quan baixen de dues. Té un cost, perquè alguna unitat deixa de vendre's en un canal, però en productes amb poc estoc i molta demanda estalvia cancel·lacions. Les regles poden anar per producte, per família o per canal. Convé tenir-les escrites en un lloc on també les vegi l'equip comercial.
Si fas servir la logística d'Amazon, les unitats que tens als seus magatzems les gestiona Amazon i no formen part de l'estoc compartit. El que sincronitzes és el que envies tu des del teu magatzem, així que porta les dues xifres separades a l'ERP.
Per què es ven de més en sincronitzar estoc amb Amazon
La sobrevenda apareix en el buit entre el moment que es ven una unitat en un canal i el moment que la resta de canals se n'assabenten. Imagina un producte amb una sola unitat. Entra una comanda a la botiga i el connector actualitza Amazon cada quinze minuts: si algú el compra a Amazon dins d'aquest interval, has venut dues unitats d'una.
Aquest buit es compon de diversos trams:
- El que triga la comanda a arribar al sistema mestre. Si la botiga avisa a l'instant amb un webhook, és molt poc; si alguna cosa consulta les comandes cada cert temps, s'hi suma aquest interval.
- El que triga el mestre a recalcular i enviar la xifra a cada canal.
- El que triga el marketplace a aplicar l'actualització. Les actualitzacions d'inventari no sempre són instantànies i algunes es processen en cua.
- Les comandes que entren al marketplace com a pendents abans de confirmar-se. Convé que reservin estoc des que apareixen, encara que no estiguin pagades.
Hi ha orígens menys evidents: vendes a la botiga física que es registren en tancar la caixa, devolucions que tornen a l'estoc abans de revisar-se o ajustos d'inventari fets a mà en un canal i no al mestre.
Freqüència d'actualització i límits de les API
La temptació és enviar-ho tot cada minut. Els marketplaces limiten quantes peticions accepten en un període, i enviar el catàleg sencer una vegada i una altra gasta aquest marge i retarda precisament les actualitzacions que importen.
Sol funcionar millor separar dos tipus d'enviament:
- Per esdeveniment: quan un producte canvia d'estoc per una venda, una devolució o una entrada de mercaderia, s'envia només aquest producte i com més aviat millor.
- Per lots: un cop al dia, o de nit, es compara l'estoc de tots els productes a tots els canals i es corregeixen les diferències que s'hagin escapat.
La comparació periòdica és la que destapa els errors silenciosos, com un SKU mal enllaçat, una actualització que el marketplace va rebutjar o una variant que ningú no va donar d'alta. Desa en un registre cada enviament amb la resposta del canal, per saber quina xifra tenia cada producte i en quin moment.
Connector multicanal o integració pròpia
Hi ha connectors i eines multicanal que enllacen la botiga amb Amazon i altres marketplaces, i amb un catàleg senzill solen ser suficients. Abans de contractar-ne un, prova'l amb els teus casos difícils:
- Productes amb variants de talla o color, i com enllaça cada variant amb la seva fitxa al marketplace.
- Packs o lots que descompten estoc de diversos components.
- Diversos magatzems, i de quin surt la xifra que es publica a cada canal.
- Què fa quan falla una actualització: si ho torna a provar, si avisa i on ho veus.
- Si permet un marge de seguretat per canal i per producte.
- Com passa les comandes a l'ERP i amb quines dades.
Una integració pròpia té sentit quan el connector no cobreix aquestes regles o no sap parlar amb el teu ERP, i també quan el volum fa que les correccions a mà ocupin hores cada setmana. Se sol muntar amb un servei intermedi que rep els avisos de cada canal, consulta el mestre i publica la xifra, amb una cua i reintents per quan un canal no respon.
Comandes d'Amazon i altres marketplaces cap a l'ERP
A més de l'estoc, les comandes dels marketplaces han d'arribar a l'ERP, i tenen les seves particularitats:
- Les dades del comprador poden arribar limitades, segons el marketplace i el tipus d'enviament.
- La factura la pot emetre el venedor o la pot generar el marketplace, segons la configuració del compte i el país.
- Les comissions del marketplace es liquiden a part i no van dins de la comanda.
- Cada comanda porta el seu identificador propi, que cal desar a l'ERP per no importar-la dues vegades.
El més pràctic sol ser donar d'alta cada marketplace com un canal o un client genèric a l'ERP, amb la seva sèrie i la seva forma de cobrament, i enllaçar cada comanda amb el seu identificador original. Si ja t'han entrat comandes repetides, a què fer quan una comanda s'envia dues vegades tens el diagnòstic. Per a la resta de fluxos, la guia sobre connectar la botiga en línia amb l'ERP repassa què cal preguntar al proveïdor.
Què has de preparar abans de sincronitzar estoc entre canals
Abans de parlar d'eines, reuneix aquesta informació:
- Quin sistema porta avui l'estoc i qui el corregeix quan no quadra.
- En quins canals vens i quantes referències publiques a cadascun.
- Si fas servir la logística d'Amazon per a part del catàleg, i per a quins productes.
- Com es corresponen els SKU de la botiga amb els de cada marketplace, i si hi ha variants o packs.
- Quantes sobrevendes o cancel·lacions has tingut els últims mesos i en quins productes.
- L'ERP o el programa de magatzem que fas servir, la seva versió i si ofereix API.
- Què es fa avui a mà, com ajustar estoc, passar comandes o revisar diferències.
Amb això et podem dir si et n'hi ha prou amb un connector ben configurat o si cal una integració. A integracions ecommerce expliquem com treballem i ens pots explicar el teu cas.



