Vi presenterar Alumio Route Builder
Anslut, orkestrera och styr integrationer i stor skala från ett visuellt gränssnitt
Lagret som Oracle har för varje butik når matchande Lightspeed POS-kassor, och varje försäljning drar ner till samma plats, så en butiks hylla räknas aldrig tyst som en annan butiks.
Oracle håller lager per plats och en kedjas kassor säljer från det kassan senast fick besked om, så de två beskriver samma butik på olika sätt senast på torsdag. Huvudkontoret ser en siffra som inkluderar en filial som stängts för renovering, butiken ser en siffra som slutade uppdateras på måndagen, och en kund lovas något som ligger tre städer bort. Personalen slutar lita på skärmen och ringer runt istället. Genom att koppla samman Oracle och Lightspeed POS kopplas varje kassa till platsen bakom den, så en försäljning minskar lagret där den fysiskt ägde rum och numret i kassan är det nummer kedjan arbetar från.
DATA SOM FLÖDAR MELLAN DEM
Produkter
Butiksplatser
Lagerpositioner
Butiksförsäljning
Återbetalningar
Prislistor
Lightspeed POS-kassor matas in i Oracle-lagerpositionen för den butik de står i, så ingen lovar en kund något som står i en filial två timmar bort.
Varje Lightspeed POS-försäljning drar ner Oracle-butiken som betjänade den, så kedjans bild av var varorna faktiskt finns förblir sann under hela handelsdagen.
Produkter och priser som publiceras från Oracle når varje Lightspeed POS-kassa tillsammans, så en ny rad konfigureras på ett ställe istället för vid varje kassa av en chef.
En ny Lightspeed POS-plats är kopplad till sin Oracle-motsvarighet med hjälp av det befintliga mönstret, så butiken fungerar korrekt från den dag dörrarna öppnas.
Alumio läser av Oracles lagerposition för varje plats och skickar den till Lightspeed POS-kassorna som står i butiken, så det en kollega ser på skärmen är vad som faktiskt finns på hyllan bakom dem.
En handelsdag stänger och Alumio bokför Lightspeed POS-försäljningar och återbetalningar till den Oracle-plats som registrerade dem, så en butiks resultat är dess eget snarare än en del av en regional totalsumma som ingen kan bryta ner.
En kund hämtar en beställning i butiken, Lightspeed POS-kassan registrerar den och Alumio tar lagret från den Oracle-platsen, så att butiken inte fortfarande visar en vara som någon redan har gått därifrån med.
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.
.svg){kind=icon}
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.
Den andra kopplingen som de flesta kedjor gör är att kollegorna i appbutiken plockar upphämtningsordrar med, eftersom Oracle vet att en order finns och Lightspeed POS vet att butiken är upptagen, och ingen av dem berättar för någon vilket paket som ska hämtas. Alumio lagrar den kopplingen bredvid denna och återanvänder den platsmappning som redan är konfigurerad, så en upphämtning plockas mot samma butik som varan kom ifrån.
Båda flödena är automatiska och de körs medvetet på olika klockor. Försäljning och återbetalningar lämnar Lightspeed POS direkt, eftersom en butiks lagerposition är fel i det ögonblick en missas, medan produkter och priser publiceras från Oracle enligt ett schema så att en ändring når varje kassa samtidigt. Båda ställs in per flöde snarare än en gång för allt. Det en kassa kan bokföra tillbaka är vad Oracle exponerar för den, så rutten är byggd kring det.
Nej, detta är konfigurerat snarare än kodat. Rutinen som tas bort är den där en chef knappar in en prisändring i varje kassa och någon annan skriver in dagens intäkter från Lightspeed POS till Oracle efteråt. Vilken butik som mappas till vilken plats, och vilken prislista var och en använder, är poster i Alumio. Där en kedja använder en ovanlig kampanjregel som mappningen inte kan uttrycka, tar Code Transformer den logiken.
Vid den tidpunkt då försäljningen slutförs, inte när sessionen är stängd, och det är värt att välja medvetet. Att vänta till dagens slut innebär att Oracle spenderar handelstimmar med att beskriva en butik som inte längre existerar, vilket är precis när någon kontrollerar tillgänglighet för en kund. Att skicka varje Lightspeed POS-försäljning allt eftersom den sker håller positionen aktiv, och sessionens stängning blir då en kontroll på dagen snarare än den första nyheten om den.
Varje Lightspeed POS-kassa rapporterar vad den skickade och Alumio registrerar platsen den skickades till, live, så ingenting om en handelsdag rekonstrueras i efterhand. En försäljning som dragits ner från en butik som Oracle redan har tagit ur bruk ser felfri ut på båda sidor medan endast antalet skiljer sig åt, så den utlöser omedelbart en varning som anger kassan och orsaken. Återförsök körs där de är konfigurerade och inga intäkter försvinner.
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.
.svg)
