Ett pris som ändras i Odoo når en kund först efter att två scheman har körts, så siffran som en kanal visar är äldre än butikens, oavsett hur lång tid det tar en given dag.
Ett flöde är en vy av katalogen just nu. DataFeedWatch bygger den utifrån vad Odoo hade när den skapades, och kanalen läser sedan flödet enligt ett eget schema, så mellan en prisändring i butiken och en kund som ser det finns det två väntetider staplade ovanpå varandra. Ingen märker det förrän en kund kommer till kassan och förväntar sig den annonserade siffran och butiken debiterar en annan. Att koppla samman Odoo och DataFeedWatch gör båda intervallen till ett avgörande, så gapet är ett känt tal snarare än något som upptäcks av en kund i en kassa.

Hur ofta Odoo läses är avsiktligt inställt snarare än att lämnas på standardinställningen, så fördröjningen mellan ett prisändring och en kanal som visar det är ett nummer som någon har valt.
Eftersom lagret följer priset slutar en slutsåld produkt att annonseras vid nästa omgång istället för att fortsätta attrahera klick som inte kan fyllas.
Varje flöde byggs från samma Odoo-katalog, så två kanaler som annonserar samma produkt fungerar inte från vyer som byggdes vid olika tidpunkter på dagen.
Uppdaterade tidsstämplar följer med flödet, så alla som undersöker ett prisklagomål kan se när siffran faktiskt avlästes istället för att behöva gissa på den efteråt.
Alumio läser Odoo-katalogen med det intervall du anger och levererar den till DataFeedWatch, så flödet byggs från butiken snarare än från en export som någon schemalagt en gång och sedan schemalagt en gång och inte har tittat på sedan dess.
En produkt som har gått slut i lager i Odoo tas bort från flödet vid nästa körning, så att annonsutgifter slutar gå emot något som ingen egentligen kan sälja under tiden, nämligen utgifter utan något bakom sig.
Varje flödespost anger tidpunkten då dess pris och aktie avlästes, så ett klagomål om en annonserad siffra besvaras genom att titta på posten snarare än att rekonstruera dagen från minnet en vecka senare.
Alumio fungerar som en central integrationsplattform mellan försäljningskanaler och logistiksystem. Order dirigeras, transformeras och valideras, samtidigt som statusuppdateringar skickas tillbaka till varje kanal.
Autentisera dina system med Alumios färdiga kopplingar. Välj bland över 200 kopplingspaket i vår marketplace, utöver obegränsade anpassade integrationer.
Definiera hur datafält mappas mellan system i ett visuellt gränssnitt. Justera format, berika poster och tillämpa affärslogik – helt utan behov av anpassad kod.
Konfigurera flöden så att de körs i realtid baserat på händelser, enligt ett schema eller både och. Minska manuell datainmatning och låt Alumio hantera förflyttning och transformering mellan system.
När din första integration är live, ansluter du enkelt ditt ERP, PIM, WMS eller CRM till samma hubb. Befintliga flöden fortsätter att köras. Ingen ombyggnad från grunden krävs.
Alumio ansluter till DataFeedWatch via sitt tillgängliga API, precis som vilket nåbart system som helst, och det du skulle ändra om flödet redan fungerade är den bättre guiden till nästa anslutning. För de flesta butiker är det sidan klicket kommer till, så ett testverktyg för landningssidor är det vanliga tillägget, eftersom Odoo och flödet bestämmer vad som annonseras och något annat bestämmer vad som händer härnäst.
Flödets form bestäms först: vilka Odoo-produkter, vilka fält och med vilket intervall. Alumio läser sedan katalogen med det intervallet och levererar den till DataFeedWatch, med lager och pris så att de två aldrig misslyckas inom en och samma post. Produkter du har uteslutit läses och ignoreras snarare än filtreras nedströms.
Nej, och det som är värt att komma ihåg är att ett flöde är en vy snarare än en kopia. Vilka Odoo-fält som visas i DataFeedWatch-flödet, hur ofta de läses och vad som exkluderar en produkt är inställningar i Alumios gränssnitt, så ett marknadsföringsteam ändrar dem utan att släppa. Där en kanal vill ha ett värde som Odoo inte har i den formen, härleder Code Transformer det.
Lika färskt som det långsammare av två intervall, vilket vanligtvis inte är det du ställer in. Alumio läser Odoo enligt det schema du väljer och DataFeedWatch publicerar utifrån det, men kanalen hämtar sedan flödet enligt sitt eget schema, så en timsgammal prisförändring kan fortfarande vara en timme från en kund. Att känna till båda intervallen är det som förvandlar en oförklarlig kassamatchning till ett aritmetiskt svar.
Det är den publicerade flödet man ska oroa sig för, inte läsningen, eftersom en flöde som misslyckades med att återuppbyggas fortsätter att fungera perfekt igår. Alumio registrerar varje läsning av Odoo med sin tidsstämpel, varnar omedelbart när en leverans till DataFeedWatch misslyckas, anger orsaken, försöker igen där det är konfigurerat, och ruttvisa meddelanden täcker ingen aktivitet, så en flöde är aldrig tyst en dag gammal.
Prata med en integrationsspecialist på Alumio. Vi tar fram rätt arkitektur för dina system, i rätt skala, så att din verksamhet förblir stabil genom alla förändringar.