Cos’è PunchOut? La guida completa per i fornitori

Come funziona PunchOut

PunchOut collega due sistemi che non sono stati progettati per comunicare tra loro: il sistema di acquisto del cliente e il tuo e-commerce. Le grandi organizzazioni acquistano tramite sistemi di eProcurement come SAP Ariba, Coupa o SAP S/4HANA, dove ogni acquisto segue regole di approvazione e viene imputato al budget corretto. Invece di copiare i tuoi prodotti in quel sistema, ti chiedono un catalogo PunchOut: un link che apre il tuo e-commerce dall’interno del loro sistema di acquisto.

Una sessione PunchOut ha quattro fasi:

1. Configurazione. Un richiedente seleziona il tuo catalogo nel proprio sistema di acquisto. Il sistema invia al tuo sistema una richiesta di configurazione con credenziali e un indirizzo di ritorno.
2. Acquisto. Il tuo e-commerce si apre nel loro browser, già connesso con il ruolo di quel cliente, con il suo catalogo e i prezzi contrattuali.
3. Ritorno del carrello. Il richiedente riempie il carrello e seleziona “ritorno” (o “checkout”). Invece di passare al tuo checkout, il carrello torna al sistema di acquisto come messaggio strutturato.
4. Approvazione e ordine. Il carrello passa attraverso l’approvazione interna del cliente. Una volta approvato, l’ordine d’acquisto viene inviato a te, che lo gestisci come qualsiasi altro ordine.

Per il cliente, il tuo e-commerce diventa parte del processo di acquisto: vede prezzi e disponibilità in tempo reale e ogni ordine segue le sue regole. Per Tu, gli ordini arrivano con il numero d’ordine d’acquisto del cliente, senza inserimento manuale dei dati da nessuna delle due parti.

PunchOut e catalogo statico a confronto

Alcuni clienti chiedono ai fornitori anche un file di catalogo statico (spesso un file CIF o un indice cXML) da caricare nel proprio sistema. I due modelli sono complementari:

Se il tuo assortimento è ridotto e stabile, un file può bastare. Se vendi migliaia di prodotti, articoli configurabili o a prezzi specifici per cliente, di solito i clienti preferiscono PunchOut.

I due protocolli: cXML e OCI

Ogni sessione PunchOut usa uno di due protocolli, scelto dal sistema del cliente. cXML (Commerce eXtensible Markup Language) scambia documenti XML tramite HTTPS ed è usato da SAP Ariba, Coupa, Jaggaer, Ivalua, Oracle, Workday e dalla maggior parte dei sistemi source-to-pay. Trasporta anche l’ordine d’acquisto, come OrderRequest. OCI (Open Catalog Interface) è il protocollo SAP, usato da SAP S/4HANA, SRM ed ECC: il tuo e-commerce viene aperto con un HOOK_URL e il carrello torna come campi di un modulo HTML denominati NEW_ITEM-*. L’ordine d’acquisto ti arriva poi tramite un canale separato.

La nostra guida cXML e OCI confronta i due protocolli messaggio per messaggio, con esempi.

Perché i clienti chiedono PunchOut

Dal punto di vista del cliente, PunchOut risolve tre problemi contemporaneamente. Primo, il controllo: ogni acquisto inizia nel sistema di acquisto e segue quindi regole di approvazione, budget e fornitori preferenziali. Secondo, la precisione: prezzi, codici prodotto e descrizioni provengono dal tuo e-commerce, così nessuno li reinserisce e le fatture corrispondono agli ordini. Terzo, la comodità per chi acquista: usa un vero e-commerce, con ricerca, filtri e configurazioni, invece di un elenco statico.

Per un fornitore, la richiesta arriva solitamente con una scadenza: un nuovo contratto, un accordo quadro o una gara che include PunchOut tra i requisiti. I fornitori che rispondono rapidamente mantengono il cliente; quelli che non possono farlo vengono spesso sostituiti da un concorrente in grado di soddisfare la richiesta.

Chi è coinvolto

Un progetto PunchOut coinvolge più persone da entrambe le parti. Identificarle subito fa risparmiare settimane:

PunchOut di livello 1 e livello 2

Potresti incontrare due livelli di PunchOut. Il livello 1 apre la pagina iniziale del tuo e-commerce: il cliente cerca e naviga lì. Il livello 2 consente al cliente di cercare nel proprio sistema di acquisto, dove viene caricato un indice sintetico dei tuoi prodotti, e apre poi il tuo e-commerce direttamente sul prodotto o sulla categoria scelti. Il livello 2 richiede un file indice statico oltre all’e-commerce in tempo reale: chiedi quindi al cliente quale livello si aspetta; la maggior parte inizia dal livello 1.

Quali sistemi di acquisto usano PunchOut

Praticamente tutti. SAP Ariba è la richiesta più comune che riceviamo dai fornitori, seguito da SAP tramite OCI e Coupa. Anche Jaggaer, Ivalua, GEP SMART, Oracle, Workday e decine di strumenti procure-to-pay per medie imprese supportano PunchOut. Consulta l’elenco completo dei sistemi supportati.

Cosa ti chiederà il cliente

L’ufficio acquisti del cliente invia solitamente la documentazione fornitore o un’email per l’attivazione. Leggila per prima cosa: elenca esattamente ciò che si aspetta. Di solito ti verranno richiesti o forniti:

• Credenziali: per cXML, identità (per SAP Ariba, l’Ariba Network ID o ANID di entrambe le aziende) e shared secret; per OCI, parametri di accesso al tuo catalogo.
• URL: l’URL di configurazione esposto dal tuo sistema e l’URL di ritorno (cXML) o HOOK_URL (OCI) sul sistema del cliente.
• Regole del catalogo: quali prodotti e prezzi deve vedere il cliente, unità di misura e uno standard di classificazione (UNSPSC o ECLASS) a un determinato livello.
• Un piano di test: un ambiente di test e le date del test di accettazione utente (UAT).
• Documenti, nelle gare e con i grandi clienti: informazioni su sicurezza e hosting, un accordo sul trattamento dei dati, referenze.

Le risposte variano in base al sistema; le nostre pagine su SAP Ariba, SAP OCI e Coupa le elencano in dettaglio.

Cosa cambia nel tuo e-commerce

PunchOut richiede all’e-commerce operazioni che i normali visitatori non eseguono mai. Questi sono gli ostacoli più comuni:

• Apertura all’interno di un altro sito. Molti sistemi di acquisto mostrano il tuo e-commerce in un frame o in una nuova finestra controllata dal sistema. Header di sicurezza come X-Frame-Options e cookie senza SameSite=None; Secure interrompono la sessione. Consulta la guida all’errore iframe.
• Accesso con l’account cliente corretto, affinché il cliente veda il proprio assortimento e i prezzi contrattuali, senza password.
• Ritorno del carrello al posto del tuo checkout, nel formato atteso dal sistema del cliente.
• Dati prodotto: unità di misura associate ai codici del cliente e un codice di classificazione su ogni prodotto. Consulta le categorie PunchOut.
• Ricezione dell’ordine: importazione dell’ordine d’acquisto approvato nel tuo e-commerce.

Un plugin PunchOut e un gateway gestiscono questi aspetti in modo standard, così l’e-commerce, il tema e il checkout esistenti continuano a funzionare per gli altri clienti.

Un piano realistico di 30 giorni

La configurazione tecnica di una connessione PunchOut su una piattaforma supportata richiede ore, non settimane. A richiedere tempo è il coordinamento con il cliente. Un piano tipico:

La coda dei test del cliente determina la data finale: alcuni uffici acquisti programmano gli UAT con settimane di anticipo. Chiedi subito le date e, se la scadenza è vicina, valuta di affidare la configurazione a specialisti, ad esempio con il nostro servizio Go-Live Assist.

Quanto costa PunchOut

Esistono tre modi comuni per soddisfare una richiesta PunchOut, con costi molto diversi:

• Un progetto di integrazione su misura realizzato da uno sviluppatore o da un’agenzia per il tuo e-commerce. Paghi sviluppo e test per ogni protocollo e cliente, oltre alla manutenzione quando cambia la tua piattaforma o il sistema del cliente.
• Un servizio con addebito per cliente, solitamente un canone mensile per ogni cliente collegato più costi di configurazione. Economico per un cliente, costoso quando ne aggiunge altri.
• Un plugin con gateway gestito come PunchOut Rocket: un prezzo annuale fisso per sito. PunchOut Rocket costa 1.950 € all’anno per WooCommerce e 2.950 € per Magento, PrestaShop, nopCommerce o REST API, con un massimo di 10 clienti inclusi.

Consulta i prezzi per il listino completo e un calcolatore di confronto.

Lista di controllo prima dei test del cliente

• Credenziali e URL dell’ambiente di test sono configurati e una sessione di test funziona dall’inizio alla fine.
• Il cliente vede solo i prodotti e i prezzi concordati nel contratto.
• Ogni prodotto dell’assortimento del cliente ha il codice di classificazione e l’unità di misura richiesti.
• Il carrello restituito contiene i tuoi codici prodotto, prezzi, quantità e valuta come atteso dal cliente.
• Sai come ti arriverà l’ordine d’acquisto (cXML OrderRequest o un altro canale concordato con il cliente) e chi lo gestisce.
• Hai un referente nel team del cliente per il giorno dei test e il cliente ha il tuo.

Errori comuni

• Iniziare dall’e-commerce prima di leggere la documentazione fornitore del cliente: spesso contiene regole sui campi che modificano la configurazione.
• Eseguire i test solo nel sistema di produzione del cliente: chiedi sempre prima l’ambiente di test.
• Dimenticare unità di misura e classificazione: i carrelli vengono rifiutati se i codici non corrispondono a quelli del cliente.
• Sottovalutare il calendario del cliente: gli slot UAT possono essere disponibili solo dopo settimane. Prenotali non appena hai le credenziali.
• Promettere conferme d’ordine, avvisi di spedizione o fatture tramite cXML senza l’opzione corretta: conferme e avvisi richiedono l’opzione OC & ASN; le fatture vengono quotate su richiesta.