Voorraad tussen Odoo en Temu synchroniseren zonder te verkopen wat je niet meer hebt

Oververkopen op Temu los je niet op met een excuus: je betaalt ervoor in annuleringen, in accountstatistieken en in een klant die al heeft betaald. En het gebeurt bijna nooit omdat de voorraad in Odoo verkeerd geteld is. Het gebeurt onderweg: tussen het moment dat een eenheid op het ene kanaal wordt verkocht en het moment dat het andere kanaal dat weet, zit een venster. Alles hieronder gaat over dat venster verkleinen en het venster dat overblijft bewust accepteren.

De hoofdvoorraad leeft in Odoo, niet in het kanaal

De regel is saai en de enige die standhoudt: een eenheid bestaat op één plek, en die plek is Odoo. Kanalen bewaren geen voorraad, ze ontvangen een gepubliceerd getal. Zodra twee systemen denken dat ze eigenaar zijn van hetzelfde getal, ontstaat het klassieke geval: Temu trekt af van zijn kopie, je webshop trekt af van de zijne, en samen bieden de twee kopieën meer eenheden aan dan er in het schap liggen. Wat je op Temu ziet, moet een functie zijn van de beschikbare voorraad in Odoo, niet een waarde die iemand met de hand in het paneel aanpast.

Verdelen is niet aftrekken

Als je dezelfde referentie op Temu, in je webshop en op een andere marketplace verkoopt, is de vraag niet hoeveel je hebt: het is hoeveel je aan elk kanaal laat zien. Alles overal publiceren maximaliseert de verkoop en vermenigvuldigt de annuleringen; verdelen in vaste quota is veilig en laat dode eenheden achter in het kanaal dat niet verkoopt. Het verstandige zit meestal in het midden: een minimumquotum voor referenties met hoge omloopsnelheid, de volledige beschikbare voorraad voor referenties met ruim voldoende voorraad. En als een deel van die goederen in een magazijn ligt dat niet van jou is, moet het meegeteld worden voordat je het publiceert: dat is het geval bij Amazon FBA binnen Odoo. Wat je ook besluit, het beleid moet als leesbare regel in Odoo staan, niet in het hoofd van degene die het kanaal beheert.

De buffer stel je in per referentie, niet per catalogus

De veiligheidsbuffer is wat je besluit niet te publiceren om de vertraging op te vangen. Globaal ingesteld (twee eenheden aftrekken van alles) is het gemakkelijk en duur: bij de referentie die één stuk per maand verkoopt, haal je twee maanden verkoop weg, en bij de bestseller redt het je nergens van. De buffer wordt berekend per referentie, en indien nodig per kanaal: hoge omloopsnelheid en een krappe verzendtermijn vragen om meer, een traag product met diepe voorraad heeft er geen nodig. In Odoo moet dat een gegeven van het product zijn dat iemand kan bekijken en aanpassen, geen constante die verstopt zit in de code van de connector.

Publiceren bij bevestiging, niet wanneer de batch aan de beurt is

Hier zit het grootste deel van het echte risico. Als de voorraad elk uur synchroniseert, is je oververkoopvenster een uur, en geen buffer lost een uur op bij een referentie met hoge omloopsnelheid. Het alternatief is publiceren wanneer de voorraad verandert: er wordt een order bevestigd, een levering gevalideerd, een ontvangst geboekt, en die beweging start de update van die referentie, niet van de tienduizend. De volledige controle blijft nodig, maar als nachtelijk vangnet, niet als hoofdmechanisme. Het is het verschil tussen wijzigingen doorduwen en op je beurt wachten, en het wordt uitgewerkt in realtime voorraad voor marketplaces.

Hoe lang het kanaal erover doet om je te geloven

Publiceren is niet hetzelfde als gepubliceerd. De aanroep kan mislukken, in een wachtrij belanden, of worden geaccepteerd en minuten later pas worden toegepast. Een serieuze connector bewaart welk getal hij heeft verstuurd, wanneer en wat het kanaal antwoordde; hij probeert opnieuw met oplopende wachttijd in plaats van te hameren; en hij neemt geen genoegen met een 200 als de waarde die er uiteindelijk staat niet die is die hij verstuurde. Zonder dat logboek is er de dag dat Temu zeven eenheden toont en Odoo nul zegt geen manier om te weten in welke stap het misging. Het is dezelfde cyclus, van de andere kant bekeken, als de binnenkomst van orders.

Wanneer je dit allemaal niet nodig hebt

Als je unieke stukken verkoopt, of weinig referenties met diepe voorraad en maar één kanaal hebt, levert direct synchroniseren je niets op: een dagelijkse controle en een ruime buffer geven je rust en besparen je een project. Het probleem ontstaat wanneer dezelfde eenheid tegelijk op twee plekken verkocht kan worden en aanvulling lang duurt. Als dat niet jouw situatie is, koop het dan niet; en als je het niet zeker weet, kijk dan eerst hoeveel annuleringen wegens voorraadtekort je dit kwartaal hebt gehad, want dat getal heb je gratis.

Wat onze connector doet

De Temu-connector voor Odoo pusht de voorraad per SKU, synchroniseert via cron en via webhook, en legt de payloads en de antwoorden van Temu vast, zodat er iets te controleren is wanneer de cijfers niet kloppen. Hij publiceert de fysieke voorraad van het magazijn dat je aan elk Temu-account toewijst, of een vaste hoeveelheid die je zelf op het product bijhoudt. Hij werkt in Odoo 17, 18 en 19. Gereserveerde hoeveelheden aftrekken, een buffer per referentie hanteren of verdelen over kanalen met eigen regels zit er niet standaard in: dat beleid bepaal jij, en het automatiseren is maatwerkontwikkeling. Als je op meer kanalen verkoopt, wordt de verdeling één keer voor alle kanalen bepaald: dat staat in meerdere marketplaces in één Odoo.

Veelgestelde vragen

Handige links binnen FlexigoTech

Wat wij hieraan doen