Español
English
Deutsch
Français
Português
Italiano
Nederlands
Polski
Sobrevendre a Temu no es paga amb una disculpa: es paga en cancel·lacions, en mètriques de compte i en un client que ja ha pagat. I gairebé mai passa perquè l'estoc estigui mal comptat a Odoo. Passa pel camí: entre que una unitat es ven en un canal i l'altre canal se n'assabenta hi ha una finestra. Tot el que ve ara va d'estrènyer aquesta finestra i d'assumir conscientment la que queda.
L'estoc mestre viu a Odoo, no al canal
La regla és avorrida i és l'única que aguanta: una unitat existeix en un sol lloc, i aquest lloc és Odoo. Els canals no guarden estoc, reben una xifra publicada. Tan bon punt dos sistemes es creuen amos del mateix número apareix el cas clàssic: Temu resta de la seva còpia, la teva web resta de la seva, i les dues còpies juntes ofereixen més unitats de les que hi ha al prestatge. El que es veu a Temu ha de ser una funció del disponible a Odoo, no un valor que algú edita a mà al panell.
Repartir no és restar
Si vens la mateixa referència a Temu, a la teva web i en un altre marketplace, la pregunta no és quant tens: és quant n'ensenyes a cadascun. Publicar-ho tot a tot arreu maximitza vendes i multiplica les cancel·lacions; repartir en quotes fixes és segur i deixa unitats mortes al canal que no ven. Allò raonable sol estar al mig: quota mínima per a les referències que roten, disponible complet per a les que tenen estoc de sobra. I si part d'aquesta mercaderia és en un magatzem que no és teu, s'ha de comptar abans de publicar-la: és el cas d'Amazon FBA dins d'Odoo. Decideixis el que decideixis, la política ha d'estar escrita com una regla llegible a Odoo, no al cap de qui porta el canal.
Una quota fixa que ningú revisa envelleix malament. Si el repartiment no s'ajusta quan canvia la rotació, acabes amb mig prestatge reservat al canal que menys ven.
El coixí es posa per referència, no per catàleg
El coixí de seguretat és el que decideixes no publicar per absorbir el desfasament. Posat global (restar dues unitats a tot) és còmode i car: a la referència que ven una unitat al mes li lleves dos mesos de vendes, i al producte estrella no el salva de res. El coixí es calcula per referència, i si cal per canal: rotació alta i termini d'enviament ajustat en demanen més, producte lent amb estoc profund no en necessita cap. A Odoo això ha de ser una dada del producte que algú pugui mirar i canviar, no una constant amagada al codi del connector.
Publicar en confirmar, no quan toqui el lot
Aquí hi ha la major part del risc real. Si l'estoc es sincronitza cada hora, la teva finestra de sobrevenda és d'una hora, i no hi ha coixí que arregli una hora en una referència que rota. L'alternativa és publicar quan l'estoc canvia: es confirma una comanda, es valida un albarà, entra una recepció, i aquest moviment dispara l'actualització d'aquesta referència, no de les deu mil. El rastreig complet continua fent falta, però com a xarxa de seguretat nocturna, no com a mecanisme principal. És la diferència entre empènyer els canvis i esperar el torn, i està desenvolupada a estoc en temps real per a marketplaces.
El que el canal triga a creure't
Publicar no és que estigui publicat. La crida pot fallar, pot posar-se en cua, pot acceptar-se i aplicar-se minuts després. Un connector seriós guarda quina xifra va enviar, quan i què va contestar el canal; reintenta amb espera creixent en lloc de collar; i no es dona per satisfet amb un 200 si el valor que queda a dalt no és el que va enviar. Sense aquest registre, el dia que Temu ensenyi set unitats i Odoo digui zero no hi haurà manera de saber en quin pas es va trencar. És el mateix cicle vist per l'altra banda que l'entrada de comandes.
Quan no cal res d'això
Si vens peces úniques, o tens poques referències amb estoc profund i un sol canal, sincronitzar a l'instant no t'aporta res: un rastreig diari i un coixí generós et deixen tranquil i t'estalviEn un projecte. El problema apareix quan la mateixa unitat es pot vendre en dos llocs alhora i la reposició triga. Si aquest no és el teu cas, no ho compris; i si no n'estàs segur, mira primer quantes cancel·lacions per manca d'estoc portes aquest trimestre, que aquesta xifra la tens gratis.
Què fa el nostre connector
El connector de Temu per a Odoo empeny l'estoc per SKU, sincronitza per cron i per webhook, i registra els payloads i les respostes de Temu perquè hi hagi alguna cosa per auditar quan les xifres no coincideixin. Publica les existències físiques del magatzem que assignes a cada compte de Temu, o una quantitat fixa que mantens tu al producte. Funciona a Odoo 17, 18 i 19. Descomptar el reservat, portar un coixí per referència o repartir entre canals amb regles pròpies no ve de sèrie: aquesta política la decideixes tu, i automatitzar-la és desenvolupament a mida. Si vens en més canals, el repartiment es decideix una vegada per a tots: això és a diversos marketplaces en un sol Odoo.
Preguntes freqüents
Cada quant s'hauria de sincronitzar l'estoc amb Temu?
Importa més el disparador que la freqüència: publicar quan canvia l'estoc i deixar un rastreig complet periòdic com a xarxa de seguretat. Un interval fix llarg és el que obre la finestra de sobrevenda.
Es publica l'estoc físic o el disponible?
El disponible: el físic menys el reservat per comandes que encara no han sortit, i menys el coixí. Publicar la quantitat física és el camí curt a cancel·lar comandes que creies que podies servir.
I si venc el mateix producte a Temu i a la meva pròpia web?
Mateix estoc mestre i una política de repartiment explícita. Si la botiga és Odoo eCommerce no hi ha repartiment que valgui: les dues vendes descompten del mateix disponible en el mateix instant, que és just el que vols.
Enllaços útils dins de FlexigoTech
El que fem sobre això
Cancel·les comandes de Temu per manca d'estoc?
Explica'ns quantes referències comparteixes entre canals, cada quant sincronitzes avui i on és la mercaderia. Et diem si el problema és el disparador, el coixí o el repartiment, i si s'arregla amb el que ja tens. Escriu a comercial@flexigobe.com o agenda una trucada.