La majoria d'integracions entre ERP i marketplace no fallen el dia que es llancen. Fallen tres setmanes després, un dissabte, quan una referència es queda en negatiu i Amazon continua venent-la. I aleshores ja ningú recorda qui va configurar què.
Un ERP (el sistema on viu de debò el teu negoci: estoc, comandes, factures, costos) i un marketplace parlen idiomes diferents. L'ERP pensa en referències internes i magatzems. Amazon pensa en ASIN, SKU de venedor i centres logístics que ni controles. Connectar-los no és "activar el connector": és decidir qui mana sobre cada dada.
Quines dades viatgen i en quina direcció
Abans de tocar res, dibuixa els fluxos. Literalment, en un full. La majoria dels desastres vénen de no tenir clar qui és la font de veritat (el sistema que decideix el valor correcte d'una dada quan dos sistemes no coincideixen) per a cada camp.
Cap enfora, de l'ERP al marketplace, sol anar:
- Catàleg: títols, descripcions, atributs, EAN, dimensions i pes.
- Preus: preu de venda i, si l'uses, preu ratllat o promocional.
- Estoc disponible: la quantitat que estàs disposat a vendre en aquest canal.
- Confirmacions d'enviament: número de seguiment i transportista.
Cap endins, del marketplace a l'ERP, ve:
- Comandes: línies, quantitats, adreça, imports i comissions.
- Canvis d'estat: cancel·lacions, comandes retingudes, adreces corregides.
- Devolucions i reemborsaments, amb el motiu, que val or per a qualitat.
- Moviments d'estoc logístic: si uses FBA, la teva mercaderia està en magatzems d'Amazon i l'ERP necessita saber-ho.
Regla pràctica: el catàleg i el preu els envia l'ERP. La comanda l'envia el marketplace. L'estoc l'envia l'ERP, però només l'estoc que tu decideixes cedir a aquest canal.
La taula de fluxos que hauries de tenir escrita
Aquesta taula és el document més útil de tot el projecte. Si el teu proveïdor no te la pot emplenar, no està preparat per integrar-te.
| Dada | Direcció | Freqüència raonable | Què passa si falla |
|---|---|---|---|
| Alta de producte | ERP cap a marketplace | Sota demanda o diària | No es publica; sense impacte en vendes actuals |
| Canvis de fitxa | ERP cap a marketplace | Diària | La fitxa queda desactualitzada; risc baix |
| Preu | ERP cap a marketplace | Cada 1-4 hores | Vens al preu vell; marge compromès |
| Estoc | ERP cap a marketplace | Cada 15-60 min | Sobrevenda, cancel·lacions i mètriques de compte danyades |
| Comandes | Marketplace cap a ERP | Cada 5-15 min | Comandes sense preparar; risc d'enviament tardà |
| Confirmació d'enviament | ERP cap a marketplace | Cada 15-30 min | El marketplace ho compta com a enviament fora de termini |
| Devolucions | Marketplace cap a ERP | Cada hora o diària | Estoc fantasma i reemborsaments descuadrats |
| Liquidacions i comissions | Marketplace cap a ERP | Quinzenal o mensual | Comptabilitat descuadrada; no veus el teu marge real |
Fixa els intervals per escrit i posa'ls on l'equip pugui consultar-los. Quan algú pregunti per què continua apareixent el preu antic, la resposta està a la taula, no a la memòria d'una persona.
Per què l'estoc és el punt que més fa mal
Vendre alguna cosa que no tens no és només un client enfadat. És una cancel·lació per part teva, i la taxa de cancel·lació abans d'enviar (comandes que anul·les tu, no el comprador) és una de les mètriques que Amazon vigila per decidir si el teu compte continua sa. Els llindars exactes convé confirmar-los a Seller Central perquè canvien, però la lògica no canvia: cancel·lar tu surt car.
El problema de fons és que entre que llegeixes l'estoc a l'ERP i el marketplace el publica passen minuts. En aquest forat pots vendre per un altre canal. Amb productes de rotació normal no passa res. Amb una referència que té 3 unitats i es ven en quatre canals, és una sobrevenda esperant a passar.
El que funciona en els comptes que gestionem:
- Coixí de seguretat per referència, no global. Si tens 3 unitats, publica 1. Si en tens 400, publica 395. Un percentatge fix del 10% no serveix per als dos casos.
- Assignació d'estoc per canal en les referències crítiques: reserves una quantitat per al marketplace i la resta no es toca.
- Tall a zero automàtic quan l'estoc baixa d'un mínim. Millor perdre tres vendes que menjar-te una cancel·lació.
- Sincronització prioritària per a les referències d'alta rotació. No totes necessiten el mateix ritme.
Temps real: per què no sempre és la resposta
"Volem sincronització en temps real" sona bé fins que veus els bloquejos per excés de peticions. Les APIs dels marketplaces tenen límits de crides (quantes peticions pots fer per minut abans que comencin a rebutjar-te), i si els satures actualitzant l'estoc de referències que no es mouen, et quedes sense marge per al que sí importa.
L'enfocament que millor aguanta combina tres ritmes:
- Per lots, per al massiu: catàleg complet i preus, una o diverses vegades al dia.
- Per esdeveniment, per al crític: quan entra una comanda en qualsevol canal, actualitza aquesta referència concreta a la resta.
- Reconciliació completa nocturna: una passada que compara tot i corregeix diferències.
Aquesta tercera és la xarxa de seguretat. Sense ella, les divergències s'acumulen durant mesos i un dia descobreixes 40 referències descuadrades.
Middleware, integració directa o connector de mercat
Tres camins, i cap no és el correcte sempre.
| Opció | Quan té sentit | Risc principal |
|---|---|---|
| Connector de mercat (els típics gestors de feeds multicanal) | Catàleg estàndard, pocs canals, equip petit | T'adaptes al seu model de dades; els casos rars no encaixen |
| Middleware o plataforma d'integració | Diversos canals, regles pròpies, necessites transformar dades | Cost recurrent i una altra peça que mantenir |
| Integració directa contra la API | Volum alt, lògica molt pròpia, equip tècnic dins | Tu mantens els canvis de la API, i el marketplace no espera |
La integració directa sembla la més barata el primer any. Deixa de ser-ho quan el marketplace retira una versió de la API i ningú al teu equip recorda que aquell endpoint existia. Si tries aquesta via, pressuposteja el manteniment, no només el desenvolupament.
Referències que no casen: la taula d'equivalències
Aquest és el fallada silenciosa més comú. El teu ERP anomena un producte CAM-AZ-42. Al marketplace està com a CAMISA-BLAVA-42. A la teva botiga és camisa_blava_42. Tot funciona fins que algú crea una variant nova i el mapatge es trenca per un costat.
Necessites una taula d'equivalències (el registre que associa la teva referència interna amb la de cada canal) que compleixi tres condicions:
- Viu en un lloc únic i amb històric, no en un Excel a l'escriptori d'algú.
- Té propietari. Una persona responsable de les altes i les baixes.
- Es valida abans de cada càrrega massiva: si una referència no té equivalència, la càrrega avisa en comptes d'inventar.
I una decisió que estalvia molt dolor: el SKU de venedor que uses al marketplace hauria de ser el mateix codi que a l'ERP sempre que puguis. Cada traducció que evites és una fallada menys.
Errors, reintents i alertes que algú llegeix
Una integració sense gestió d'errors és una integració que ja està fallant i encara no ho saps.
- Reintents amb espera creixent: si la API rebutja una crida, reintenta als 30 segons, després als 2 minuts, després als 10. No martillegis.
- Cua de fallits: el que no entra després dels reintents va a una llista visible, no al buit.
- Distingeix error temporal d'error de dades: un timeout es reintenta; un EAN invàlid no s'arregla reintentant, cal corregir-lo a mà.
- Alertes amb llindar: no avisar per cada fallada, o deixaran de llegir-se en dos dies. Avisa si fallen més de X en una hora, o si fa més de Y minuts que no entra cap comanda.
Aquest últim punt importa més del que sembla. "Fa tres hores que no entra cap comanda" és l'alerta que detecta la meitat dels problemes reals, i gairebé ningú la té configurada.
Com provar sense carregar-te les comandes reals
- Usa l'entorn de proves del marketplace per al flux bàsic. No ho reprodueix tot, però valida formats i permisos.
- Arrenca amb un subconjunt de 20 o 30 referències poc crítiques. Un pilot real val més que un entorn de proves perfecte.
- Mode només lectura primer: deixa que la integració llegeixi comandes i les escrigui a l'ERP durant una setmana sense que empènyer estoc ni preus. Compara a mà.
- Prova els casos lletjos: comanda cancel·lada abans de preparar, devolució parcial, producte esgotat a mig sincronització, comanda amb dues línies del mateix SKU, adreça modificada pel comprador.
- Tingues un interruptor de parada. Si alguna cosa va malament un divendres a les deu del vespre, algú ha de poder tallar la sincronització de preus sense trucar al desenvolupador.
Què demanar-li al teu proveïdor d'ERP abans de signar
Preguntes concretes. Si n'esquiva alguna, apunta-ho:
- La connexió, és nativa o va per un tercer, i qui dona suport quan falla.
- Quins camps sincronitza exactament i en quina direcció. Per escrit.
- Quina freqüència suporta per tipus de dada i si hi ha límit d'operacions incloses a la tarifa.
- Com gestiona els errors: si hi ha panell de fallits i reintents automàtics.
- Si suporta multi-magatzem i reserva d'estoc per canal.
- Qui actualitza la integració quan el marketplace canvia la seva API, i amb quin termini.
- Si pots exportar la teva taula d'equivalències i el teu històric el dia que te n'anis.
- Si hi ha entorn de proves separat del de producció.
La setena és la que més incomoda el comercial i la que més et protegeix a tu.
Per on començar aquesta setmana
- Dibuixa la taula de fluxos amb les teves dades reals: què viatja, cap a on, cada quan i què passa si falla. Una hora de feina que t'estalvia setmanes.
- Revisa les teves 20 referències més venudes i comprova si l'estoc de l'ERP coincideix avui amb el publicat a cada canal. Si no coincideix, ja tens el primer problema localitzat.
- Configura una alerta d'absència de comandes: si passen X hores sense entrar-ne cap, que avisi. És la detecció més barata que existeix.
- Defineix coixins de seguretat per rotació, no un percentatge únic, i aplica'l primer a les referències amb menys de cinc unitats.
- Escriu qui és el propietari de la taula d'equivalències, amb nom i cognoms. Si no ho és ningú, ho serà el caos.