Vi presenterar Alumio Route Builder
Anslut, orkestrera och styr integrationer i stor skala från ett visuellt gränssnitt
En namngiven kund vid disken når SAP som en försäljning mot eget konto, så en köpare som hämtar i butik faktureras enligt deras villkor istället för att ringas upp utan uppringning.
En kassa är byggd för att sälja till den som står framför den, och SAP kommer inte att bokföra en försäljning till en kund som den inte redan har som affärspartner. Så en köpare som hämtar från en butik blir uppringd som en kontantförsäljning, och kreditvillkoren, kontot och prissättningen de förhandlade fram gäller överallt utom den enda platsen där de fysiskt dök upp. Någon inom ekonomiavdelningen bygger om den senare från ett kvitto, om kvittot alls kan hittas. Att koppla samman SAP och Odoo POS stänger den luckan: kassan kan identifiera en kund som redan finns i SAP, och försäljningen bokförs mot dem.
DATA SOM FLÖDAR MELLAN DEM
Affärspartners
Kundpriser
POS-transaktioner
Betalningsrader
Produktregister
Butiksplatser
En kund som redan finns i SAP kan identifieras i Odoo POS-kassan, så en inkasso i butik bokförs mot deras konto snarare än som en anonym kontantförsäljning.
Eftersom försäljningen når SAP med kunden kopplad, slutar ekonomiavdelningen att rekonstruera vilket kvitto som tillhörde vilket konto från en hög med papper i slutet av månaden.
Butikstransaktioner visas i samma kontohistorik som allt annat kunden köper, så en fråga om en leverans och en fråga om en upphämtning besvaras från ett och samma ställe.
Anonyma försäljningar går fortfarande igenom med den hastighet en kö behöver, eftersom identifiering av en kund är ett steg som kassören tar bara när det finns en kund att identifiera.
Alumio ansluter till Odoo POS via sitt tillgängliga API, precis som vilket annat nåbart system som helst, så en kassa kan söka upp en kund som redan finns i SAP och bokföra försäljningen mot kontot istället för som en kontanttransaktion.
De priser som SAP håller för den kunden når Odoo POS-sessionen, så en köpare som hämtar i butik debiteras vad deras konto anger snarare än hyllpriset som en kassör råkar se på skärmen framför sig.
Anonym och identifierad försäljning kommer tillbaka från samma kassa i ett flöde, och Alumio dirigerar var och en till rätt behandling i SAP, så en butik behöver inte två kassor eller två processer för att betjäna båda typerna av kunder.
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 butik behöver något som huvudkontoret inte har, och det är oftast så den tredje kopplingen uppstår. När en Odoo POS-försäljning väl har en kund blir själva kvittot värt att skicka, så en digital kvittotjänst är det vanliga tillägget, eftersom en namngiven kund har en adress och det är ett papperskvitto som försvinner innan en retur. Alumio har den kopplingen tillsammans med SAP-kvittot, så kvittot och den bokförda försäljningen beskriver samma transaktion.
Kunden måste lösas innan något bokförs, vilket är den ordning som är viktig här. Alumio slår upp den affärspartner som SAP redan har, och när kassan har den, skrivs varje slutförd Odoo POS-transaktion mot kontot med dess betalningsrader. Försäljning utan kundidentifierad bokförs som den alltid gjorde, så kassan fortsätter att arbeta med den hastighet en kö behöver.
Nej, och den version som en butikschef känner igen är den användbara: vilket fält Odoo POS-kassören skriver in, vad som händer när en kund inte hittas och om försäljningen väntar eller slutförs anonymt. Det är inställningar i Alumio snarare än logik i ett skript. SAP:s partnerstrukturer varierar beroende på hur verksamheten konfigurerades, så anpassad logik förblir tillgänglig via Code Transformer där en sökregel inte kan uttryckas som en mappning.
En affärspartner som redan finns, eftersom en kassa inte kan skapa en som SAP accepterar. SAP har en kund som en partnerpost med de roller och kontostrukturer som avgör hur en försäljning bokförs, så en Odoo POS-transaktion måste peka på en snarare än att beskriva en person. Att konfigurera kassan för att söka upp en befintlig partner, och att slutföra anonymt när det inte finns någon, håller båda typerna av försäljning igång.
En försäljning som tillskrivs ingen är resultatet att fånga, eftersom den fortfarande balanserar. Om kundsökningen misslyckas bokförs Odoo POS-transaktionen som en kontantförsäljning i SAP och handelskontot ser den aldrig, vilket inget nedströms flaggar. Alumio övervakar varje överföring i realtid och loggar transaktionen och den sökning som försöktes, så en misslyckad matchning utlöser en omedelbar varning med orsaken, återförsök körs där de är konfigurerade och olösta försäljningar förblir listade istället för att stängas tyst.
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)
