Punto di partenza per il fornitore. Come caricare, validare e pubblicare un indice di prodotti prima del processo d'acquisto reale.

Pubblicazione e Gestione Cataloghi

Il passo iniziale che precede la compravendita è sempre mettere a disposizione del cliente i propri prodotti.

Supporto in F-Merchant: utile quando il progetto non richiede PunchOut completo o quando il buyer preferisce cataloghi hosted/statici.

Direzione tipica: in uscita dal fornitore verso la piattaforma procurement o network del buyer.

Chi deve leggerla: catalog manager, integration developer, team commerciale B2B che governa assortimenti e listini.

Sistemi coinvolti di solito: PIM o ERP del fornitore, F-Merchant, piattaforma eProcurement del buyer, eventuale marketplace/network intermedio.

Il cXML definisce un meccanismo standard per il caricamento dei cataloghi statici, noto come IndexCatalogTransaction. Si tratta della transazione utilizzata da piattaforme come SAP Ariba, Coupa e Jaggaer per ricevere e indicizzare l’elenco dei prodotti offerti da un fornitore. In pratica, il fornitore prepara un file cXML contenente tutti gli articoli e lo trasmette alla piattaforma del cliente, che lo elabora e lo rende disponibile agli utenti interni per la ricerca e la creazione di ordini.

Checklist minima di implementazione

Per pubblicare un catalogo statico in modo affidabile servono almeno:

• identificazione del buyer o del tenant che riceve il catalogo;
• regole chiare di estrazione da ERP, PIM o listino commerciale;
• codici articolo stabili (SupplierPartID) e non riutilizzati;
• valuta, unità di misura e classificazioni coerenti con le aspettative del buyer;
• processo di pubblicazione, validazione e sostituzione versioni;
• gestione degli articoli rimossi o non più ordinabili.

Se il catalogo viene caricato ma non ha coerenza anagrafica e prezzi affidabili, il buyer lo considererà inutilizzabile anche se il file è stato tecnicamente accettato.

Formati del Catalogo Statico

Il documento cXML di un catalogo statico segue la struttura classica Header/Body, ma il corpo della transazione ruota attorno all’elemento IndexItem. Ogni IndexItem rappresenta un singolo articolo nel catalogo e ne descrive le informazioni essenziali: codice fornitore, descrizione, prezzo unitario, unità di misura e classificazione merceologica.

Di seguito un esempio completo e realistico di un IndexItem:

<IndexItem>
  <IndexItemAdd>
    <ItemID>
      <SupplierPartID>MAT-2024-00158</SupplierPartID>
    </ItemID>
    <ItemDetail>
      <UnitPrice>
        <Money currency="EUR">42.50</Money>
      </UnitPrice>
      <Description xml:lang="it">Risma carta A4 80g/m2 - 500 fogli, bianca per uso ufficio</Description>
      <UnitOfMeasure>EA</UnitOfMeasure>
      <Classification domain="UNSPSC">14111507</Classification>
      <LeadTime>3</LeadTime>
    </ItemDetail>
  </IndexItemAdd>
</IndexItem>

Campi principali di un IndexItem

La piattaforma del cliente riceve il file, lo valida e, se non vi sono errori, lo pubblica nel proprio motore di ricerca interno. Gli utenti autorizzati potranno quindi cercare e selezionare gli articoli direttamente dal catalogo indicizzato, senza necessità di contattare il fornitore.

Campi minimi richiesti

Per un IndexItem realmente usabile, questi elementi sono normalmente indispensabili:

Campi come lead time, immagini, manufacturer part number o attributi estesi possono essere facoltativi nello standard, ma spesso fanno la differenza sulla qualità percepita del catalogo.

Esempio minimo valido di riga catalogo

<IndexItem>
  <IndexItemAdd>
    <ItemID>
      <SupplierPartID>SKU-001</SupplierPartID>
    </ItemID>
    <ItemDetail>
      <UnitPrice>
        <Money currency="EUR">12.50</Money>
      </UnitPrice>
      <Description xml:lang="it">Guanti monouso nitrile taglia M</Description>
      <UnitOfMeasure>BX</UnitOfMeasure>
      <Classification domain="UNSPSC">42132203</Classification>
    </ItemDetail>
  </IndexItemAdd>
</IndexItem>

Questo è il nucleo minimo che dovrebbe essere validato prima di affrontare cataloghi completi con migliaia di righe o attributi estesi.

Sequenza visiva del flusso

ERP / PIM / Listino         F-Merchant                 Buyer Procurement
       |                        |                              |
       | -- dati articolo ----> |                              |
       |                        | -- IndexCatalogTransaction ->|
       |                        |                              |
       |                        | <- esito validazione ------- |
       |                        |                              |

Lettura pratica del diagramma:

1. ERP, PIM o listino commerciale alimenta i dati prodotto;
2. F-Merchant costruisce il payload catalogo;
3. la piattaforma buyer valida e indicizza il contenuto;
4. l’esito guida correzioni o pubblicazione definitiva.

Collegamento con il mondo Dinamico

Il catalogo statico e il PunchOut rappresentano due modalità complementari, non alternative, per rendere disponibili i prodotti all’interno di una piattaforma di e-procurement.

Catalogo Statico: caricamento periodico

Il catalogo statico prevede l’invio periodico di un file cXML (o CIF) contenente l’intero listino del fornitore. Questo approccio risulta particolarmente adatto quando:

• La gamma di prodotti è stabile e non subisce variazioni frequenti.
• I prezzi sono concordati contrattualmente e restano fissi per periodi definiti.
• Non è necessario mostrare disponibilità in tempo reale o configurazioni personalizzate.

Il vantaggio principale è la semplicità: una volta caricato e validato, il catalogo resta consultabile senza ulteriori interazioni con i sistemi del fornitore.

PunchOut: navigazione in tempo reale

Quando si vendono prodotti configurabili, il solo file XML statico impone vincoli rilevanti: impossibilità di mostrare prezzi aggiornati in tempo reale, assenza di scontistica dinamica legata a specifici accordi, difficoltà nel gestire varianti e personalizzazioni.

Il PunchOut supera queste limitazioni consentendo all’utente della piattaforma di “uscire” temporaneamente dal portale di e-procurement per navigare direttamente il sito (o e-commerce) del fornitore. Al termine della selezione, il carrello viene trasferito automaticamente alla piattaforma sotto forma di ordine cXML. Questo meccanismo è ideale per:

• Prodotti con configurazioni variabili (dimensioni, materiali, accessori).
• Listini con prezzi dinamici legati a volumi, promozioni o accordi specifici.
• Articoli la cui disponibilità cambia frequentemente.

Due strumenti, una strategia

Nella pratica, molte organizzazioni adottano entrambi gli approcci contemporaneamente: il catalogo statico per i materiali di consumo a prezzo fisso (cancelleria, DPI, materiale da imballo) e il PunchOut per le categorie merceologiche più complesse o personalizzabili. La scelta non è esclusiva e dipende dalla natura del prodotto, non dalla piattaforma utilizzata.

[!TIP] Quando scegliere l’uno o l’altro? Se il listino è composto da articoli standard con prezzi fissi e aggiornamenti trimestrali o semestrali, il catalogo statico è la soluzione più efficiente. Se invece i prodotti richiedono configurazione, i prezzi variano in base al cliente o al volume, oppure la disponibilità è soggetta a variazioni frequenti, il PunchOut offre un’esperienza più accurata e aggiornata. In molti casi la combinazione di entrambi rappresenta la strategia ottimale.

Note di implementazione F-Merchant

Nel contesto F-Merchant, la parte critica dei cataloghi non è generare XML, ma garantire coerenza tra anagrafiche commerciali, listini B2B e ciò che il buyer riceverà. In pratica bisogna allineare:

• SupplierPartID con SKU o codici prodotto interni stabili;
• listino buyer con prezzi, valuta e condizioni contrattuali corrette;
• unità di misura coerenti con il modo in cui l’ordine verrà poi emesso;
• classificazioni merceologiche richieste dalla piattaforma buyer;
• logica di deprecazione o rimozione articoli senza creare ordini su codici non più validi.

Se il catalogo e l’ordine non parlano lo stesso linguaggio di codici e unità di misura, i problemi emergono solo più avanti, quando i buyer iniziano a ordinare.

Mapping minimo consigliato

Errori comuni e cause tipiche

Test minimi consigliati

Prima del go-live, almeno questi test dovrebbero essere obbligatori:

1. caricamento di un catalogo minimo con pochi SKU validi;
2. verifica di ricerca e visualizzazione lato buyer;
3. controllo di prezzo, valuta e unità di misura;
4. ordine di prova su uno SKU pubblicato;
5. aggiornamento catalogo con modifica prezzo o descrizione;
6. rimozione o sostituzione di uno SKU e verifica del comportamento buyer.