Vi presenterar Alumio Route Builder
Anslut, orkestrera och styr integrationer i stor skala från ett visuellt gränssnitt
Webbutiksordrar och avräkningar från Lightspeed eCommerce anländer till Oracle som poster som ekonomiavdelningen kan avsluta månaden med, snarare än som en rapport som någon stämmer av manuellt i slutet av varje månad.
En webbutik genererar försäljning hela dagen och finansavdelningen behöver den som bokföringsposter, i rätt företag, mot rätt konton. Oracle accepterar inte en försäljning som inte anger vilken del av verksamheten den tillhör, så någon bestämmer det per order, vanligtvis i månadsslutet, vanligtvis från ett kalkylblad som ingen annan kan följa. Lightspeed eCommerce till Oracle-integrationen avgör dessa beslut en gång och tillämpar dem på allt. Varje order anländer redan tilldelad, och dagens intäkter kopplas tillbaka till vad betalningsleverantören faktiskt betalade ut.
DATA SOM FLÖDAR MELLAN DEM
Ordrar
Orderrader
Kunder
Betalningar
Återbetalningar
Totala avräkningar
Beställningar når Oracle, tilldelade rätt del av verksamheten, allt eftersom de kommer in, så att avsluta månaden är en uppföljning snarare än en vecka där man utarbetar var saker hör hemma.
Betalningar och återbetalningar anländer tillsammans med de beställningar de avser, så beloppet på banken och beloppet på kontona kan matchas utan manuell jämförelse.
En återbetalning som ges i webbutiken når Oracle som en reduktion, så kontona visar vad som faktiskt sparades snarare än en försäljningssiffra som någon justerar senare från minnet.
Timmarna som läggs ner på att kopiera webbutiksförsäljning till kontona kommer tillbaka, eftersom varje order anländer med sin kund, rader och summor redan i den form som reskontran önskar.
En beställning görs i Lightspeed eCommerce och Alumio skapar posten i Oracle mot den del av verksamheten som gjorde försäljningen, så kontona förblir aktuella utan att någon bestämmer var den hör hemma varje gång.
Dagens beställningar, betalningar och återbetalningar anländer alla tillsammans, så finansavdelningen kan koppla summan i Oracle till vad processorn betalade ut och omedelbart se om de två siffrorna av någon anledning inte stämmer överens.
En kund får återbetalning i webbutiken och Oracle får rabatten, så ingen upptäcker vid kvartalets slut att den rapporterade försäljningen fortfarande inkluderar pengar som redan hade gått tillbaka till en kund flera veckor tidigare.
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.
En skattetjänst är ett vanligt tillägg när en butik säljer över gränserna, eftersom den skattesats som gäller beror på var kunden befinner sig och vad de köpte, och varken webbutiken eller kontona vill äga den logiken. Båda kopplingarna finns på samma plats, så den skattesats som tillämpas i kassan är den kontona förväntar sig att se.
Ja, och det viktiga att ta ställning till är när en order blir en bokföringspost. En varukorg är inte en försäljning och en levererad order är det ibland inte heller, så Alumio agerar i det ögonblick du behandlar som slutgiltig, vanligtvis betalning, och skickar ordern, dess rader och dess betalning tillsammans. Återbetalningar följer samma väg så ingenting korrigeras manuellt.
Nej, och personen som normalt sett sätter upp detta sitter inom ekonomi eller drift snarare än i ett utvecklingsteam. De väljer vilka ordrar som ska vart, och de ändrar det själva när företaget lägger till ett land eller ett varumärke, utan att vänta på någon. För enstaka regler som ett formulär verkligen inte kan beskriva finns Kodtransformatorn där.
När du bestämmer dig för att det görs, är det värt att göra ett avsiktligt beslut. Vissa företag räknar en försäljning när den betalas, andra när den skickas, och skillnaden syns i varje månadsjämförelse efteråt. Oracle behöver också veta vilken del av verksamheten försäljningen tillhör innan de tar emot den alls, så att tilldelningen görs en gång snarare än att diskuteras per beställning.
Kontobalansen, förutom processorns avbrott, är det misslyckande som äter upp en eftermiddag, eftersom alla ordrar finns där och summan fortfarande inte är i balans. Alumio har en livevy över varje överföring och en registrering av siffrorna bakom den. När Oracle inte tar emot något meddelas någon direkt och får veta orsaken, och nya försök körs där de är konfigurerade, så ingen försäljning går oregistrerad utan att någon märker det.
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)
