Med punchout handlar köparen i leverantörens webbutik utan att lämna sitt eget inköpssystem. Köparen klickar på leverantören i inköpssystemet, till exempel SAP Ariba, Coupa eller Visma Proceedo, och hamnar inloggad i leverantörens butik med sina avtalade priser. När varukorgen är klar går den inte till kassan. Den skickas tillbaka till inköpssystemet, där den attesteras som vilket inköp som helst.
Båda parter får något de annars saknar. Köparen behåller sin attest, sin budgetkontroll och sina avtal på ett ställe. Leverantören visar aktuella priser, lagersaldon och produktval direkt, i stället för att skicka en katalogfil som är inaktuell när den läses in.
Så går en punchout till
- Köparen startar i inköpssystemet och väljer leverantören.
- Inköpssystemet öppnar leverantörens butik. Det skickar med vem köparen är och vart varukorgen ska tillbaka.
- Köparen handlar i butiken med sina egna priser, sitt sortiment och leverantörens aktuella lager.
- Varukorgen skickas tillbaka till inköpssystemet i stället för att gå till kassan.
- Köparen attesterar internt. Varukorgen är nu en rekvisition, och ingen order finns ännu hos leverantören.
- Inköpsordern skickas till leverantören som ett eget meddelande, ofta dagar efter att varukorgen fylldes.
Steg 4 och 6 är två olika händelser, och det är den viktigaste skillnaden mot vanlig e-handel. Leverantören ser en varukorg som lämnar butiken, men vet inte om, eller när, den blir en order.
OCI och cXML
| OCI | cXML | |
|---|---|---|
| Ursprung | SAP | Ariba |
| Hur varukorgen skickas | Formulärfält via köparens webbläsare | XML-meddelande, också via webbläsaren |
| Inloggning | Användarnamn och lösenord i anropet | Delad hemlighet och parternas identiteter i meddelandet |
| Ordern | Ingår inte, skickas på annat sätt | Kan skickas som cXML (OrderRequest) |
| Bekräftelse, leveransavisering, faktura | Ingår inte | Kan skickas som cXML |
| Vanligt hos | SAP-baserade inköpssystem | Ariba, Coupa och många andra |
OCI är enklare att komma igång med, eftersom det bara handlar om att fylla och skicka ett formulär. cXML kräver mer men täcker hela flödet, och det är ofta det som avgör vilket av dem köparen kräver. Många inköpssystem stöder båda.
Punchout jämfört med andra sätt att ta emot B2B-order
| Sätt | Vem håller sortimentet aktuellt | Köparens attest | Passar när |
|---|---|---|---|
| Punchout | Leverantören, i sin butik | I köparens inköpssystem | Köparen har ett inköpssystem och ett stort eller rörligt sortiment |
| Statisk katalog | Köparen läser in leverantörens katalogfil | I köparens inköpssystem | Sortimentet är litet och priserna ändras sällan |
| EDI | Ingen, EDI skickar dokument och inget sortiment | Före ordern, utanför EDI | Köparen vet redan vad som ska beställas, i stora volymer |
| Inloggad B2B-butik eller kundportal | Leverantören | Ingen, eller en attest i butiken | Köparen saknar inköpssystem |
Punchout och EDI konkurrerar inte. Punchout tar hand om urvalet och varukorgen, och EDI eller cXML tar ofta hand om ordern, orderbekräftelsen och fakturan som följer.
Åt båda hållen
Samma teknik används från två håll, och ett företag som både köper och säljer möter ofta båda.
Som leverantör tar du emot köpare som kommer från sina inköpssystem. Butiken måste känna igen köparen som en kontakt hos rätt kund, visa den kundens priser och sortiment och skicka varukorgen tillbaka i det format köparen kräver. Sedan ska den inkommande ordern kunna matchas mot det köparen såg.
Som köpare går du själv ut till dina leverantörers butiker från ditt eget system. Varukorgen som kommer tillbaka ska bli rader på en inköpsorder, och leverantörens artikelnummer behöver matchas mot dina egna artiklar. Annars står raderna som fritext, och då fungerar varken lagerstyrning eller uppföljning.
Var det brukar gå fel
Priset hinner ändras. Varukorgen bär ett pris, men ordern kommer först efter attesten. Ändrar leverantören priset under tiden finns två sanningar: priset köparen godkände och priset i butiken nu. Bestäm i förväg vilket som gäller och hur länge ett varukorgspris håller.
Artikelnummer och enheter matchar inte. Leverantören skickar sitt artikelnummer och sin enhet, köparens system förväntar sig sina. Styck, förpackning och kartong måste översättas, och ofta krävs en varuklassning som UNSPSC för att inköpssystemet ska kunna kontera raden.
Ordern går inte att knyta till varukorgen. Ordern kommer som ett separat meddelande, ibland med ändrade antal eller strukna rader. Utan en referens tillbaka till varukorgen blir den en order bland andra, och en konfigurerad produkt tappar sina val.
Användaren är inte kunden. I OCI delar ofta alla köpare hos en kund samma tekniska inloggning. Då vet leverantören vilket företag som handlar men inte vilken person, och det syns i orderhistorik och ansvar.
Testet tar längre tid än bygget. Varje köpare har sitt eget inköpssystem, med egna fältkrav och en testmiljö som ska godkännas innan produktion. Räkna med att varje ny kund är ett eget litet projekt, även när standarden är densamma.
