Prissättning för inloggade kunder som lösts av SAP S/4 HANA når en WordPress-webbplats i samma ögonblick som den begärs, så en handelskund ser sina egna villkor och en anonym besökare ser listpriser.
En WordPress-webbplats är där de flesta företag faktiskt möter sina kunder, och det är oftast den sista platsen deras prissättningslogik når. SAP S/4 HANA beräknar ett pris per kund genom villkor när det efterfrågas, så att publicera en siffra i en sidmall innebär att publicera en kunds svar till alla. De flesta webbplatser löser detta genom att inte visa någonting och bjuda in till en förfrågan, vilket kostar beställningar. WordPress till SAP S/4 HANA-integrationen frågar efter S/4 i förfrågningstillfället, när besökaren har identifierats, så att webbplatsen kan visa ett riktigt pris till den person som har rätt till det.

En inloggad kunds pris begärs från SAP S/4 HANA när sidan renderas, så webbplatsen visar vad deras konto har rätt till snarare än någon annans belopp.
Eftersom ingen kundspecifik siffra publiceras på webbplatsen kan ett kontos förhandlade villkor inte bli synliga för en besökare som helt enkelt laddat samma produktsida.
Formulär som fylls i i WordPress når SAP S/4 HANA som register mot rätt konto, så en förfrågan blir något som företaget kan agera utifrån snarare än ett e-postmeddelande i en inkorg.
Villkoren stannar kvar i S/4 istället för att approximeras i ett plugin, så priset som visas på webbplatsen och priset på den resulterande fakturan produceras enligt exakt samma regler.
En företagskund loggar in och öppnar en produktsida. Alumio begär priset från SAP S/4 HANA för det kontot och sidan renderar det, så siffran på skärmen är den som en beställning faktiskt skulle läggas på.
Ett formulär som skickas in på WordPress skapar posten i SAP S/4 HANA mot det matchande kontot, så en offertförfrågan hamnar i samma kö som allt annat istället för att vänta i en delad postlåda tills den uppmärksammas.
Produkttillgänglighet från SAP S/4 HANA visas för en inloggad kund för de platser som betjänar dem, så webbplatsen lovar inte att lagerhållning sker någonstans som aldrig kommer att skickas till deras adress från första början.
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.
Ett CRM-system är det vanliga tillägget, eftersom en förfrågan som når ERP-systemet som en post fortfarande behöver någon som äger den och följer upp den. Alumio hanterar dessa kopplingar centralt och återanvänder den kontomatchning som redan är konfigurerad, så en webbplatsförfrågan, en CRM-möjlighet och en S/4-kund beskriver samma relation.
Ja, och vem som har identifierats avgör om prissättning ska begäras överhuvudtaget. För en inloggad kund som matchas med ett S/4-konto kan Alumio begära priset live när sidan behöver det. För anonyma besökare begärs inget kundspecifikt, och förfrågningar skickas inåt allt eftersom de skickas in.
Nej, detta är konfigurerat snarare än kodat. Kundidentitet, prisförfrågningar och S/4-villkoren bakom dem konfigureras i Alumio snarare än inbyggda i ett tema eller ett plugin, vilket är det som förhindrar att prissättningslogiken hamnar på två ställen samtidigt. För en regel som mappningen inte kan uttrycka hanteras den av Code Transformer i flödet.
Endast de som webbplatsen har identifierat, vilket gör identifiering till det första designbeslutet snarare än en eftertanke. S/4 löser ett pris per kund, så en siffra som efterfrågas utan att veta vem som frågar är antingen fel eller tillhör någon annan. Det fungerande mönstret är listpriser för anonyma besökare och en livesökning när ett konto har matchats.
Att priset når fel kundgrupp är det avgörande felet här, eftersom ett segment ser ett annats villkor och sidan ser helt normal ut. Alumio begär priset för det identifierade kontot istället för att cacha en delad kopia, övervakar varje sökning live och loggar kontot som den löste, så en avvikelse meddelas omedelbart med orsaken. Återförsök körs där de är konfigurerade, och en olöst begäran visas som otillgänglig istället för att tyst falla tillbaka.
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.