Inoltro degli ordini finali, completi di dettagli di spedizione, fatturazione e termini di pagamento.

Ordini di Acquisto (Purchase Orders)

L’Ordine di Acquisto (OrderRequest) è il documento ufficiale con cui il cliente (l’acquirente) formalizza l’acquisto verso il fornitore.

Supporto in F-Merchant: centrale in tutti i progetti in cui F-Merchant riceve l’ordine finale dal sistema procurement del buyer.

Direzione tipica: dal buyer o dal network verso F-Merchant, con successivo allineamento verso ERP e logistica.

Chi deve leggerla: integration developer, ERP team, operations team che gestisce evasione e sincronizzazione stato ordine.

Sistemi coinvolti di solito: piattaforma eProcurement buyer, F-Merchant, ERP del fornitore, sistemi di fulfillment o magazzino.

Contiene tutte le informazioni tecniche e legali per procedere all’evasione.

Checklist minima di implementazione

Per ricevere correttamente un OrderRequest servono almeno:

• endpoint di ricezione stabile e autenticato;
• riconoscimento corretto di buyer, destinatario e credenziali tecniche;
• mapping affidabile di orderID, righe, SKU, quantità, valuta e unità di misura;
• gestione coerente degli indirizzi ShipTo e BillTo;
• instradamento verso ERP, OMS o middleware senza perdere riferimenti di riga;
• regole chiare per new, update e delete.

Se l’ordine entra ma non mantiene chiavi e riferimenti fino all’ERP, il flusso è solo formalmente integrato.

Struttura dell’OrderRequest

L’Ordine in cXML è strutturato in tre macro-sezioni:

1. OrderRequestHeader: Contiene le intestazioni (Numero Ordine, Date, Indirizzi di spedizione e fatturazione, Termini di pagamento).
2. ItemOut: I dettagli di ogni singola riga d’ordine (Prodotto, Quantità, Prezzo Unitario, Specifiche).
3. Sommario (Summary): Il totale dell’ordine e dei costi aggiuntivi stimati (tasse, spedizioni preventivate).

<OrderRequest>
   <OrderRequestHeader orderID="PO-12345" orderDate="2026-03-02" type="new">
      <Total>
         <Money currency="EUR">1250.00</Money>
      </Total>
      <ShipTo>
         <Address>
            <Name xml:lang="it">Sede Operativa Acquirente</Name>
            <PostalAddress>
               <Street>Via Roma 10</Street>
               <City>Milano</City>
               <PostalCode>20121</PostalCode>
               <Country isoCountryCode="IT">Italia</Country>
            </PostalAddress>
         </Address>
      </ShipTo>
      <BillTo>
         <Address>
            <Name xml:lang="it">Ufficio Amministrativo Acquirente</Name>
            <PostalAddress>
               <Street>Corso Europa 22</Street>
               <City>Roma</City>
               <PostalCode>00186</PostalCode>
               <Country isoCountryCode="IT">Italia</Country>
            </PostalAddress>
         </Address>
      </BillTo>
   </OrderRequestHeader>
   <ItemOut quantity="10" lineNumber="1">
      <ItemID>
         <SupplierPartID>PROD-A</SupplierPartID>
      </ItemID>
      <ItemDetail>
         <UnitPrice>
            <Money currency="EUR">125.00</Money>
         </UnitPrice>
         <Description xml:lang="it">Prodotto A</Description>
         <UnitOfMeasure>EA</UnitOfMeasure>
      </ItemDetail>
   </ItemOut>
</OrderRequest>

Campi minimi richiesti

In un progetto reale, questi campi sono quasi sempre indispensabili:

Elementi come centro di costo, riferimenti contrattuali, tax detail o commenti possono essere opzionali a livello standard, ma spesso vengono resi obbligatori dalle regole del buyer.

Esempio minimo valido di ordine

Questo è un esempio più essenziale, utile per capire il nucleo minimo da far passare in test:

<OrderRequest>
  <OrderRequestHeader orderID="PO-2026-00421" orderDate="2026-03-02T09:15:00+01:00" type="new">
    <Total>
      <Money currency="EUR">250.00</Money>
    </Total>
    <ShipTo>
      <Address>
        <Name xml:lang="it">Magazzino Cliente</Name>
      </Address>
    </ShipTo>
  </OrderRequestHeader>
  <ItemOut quantity="2" lineNumber="1">
    <ItemID>
      <SupplierPartID>SKU-001</SupplierPartID>
    </ItemID>
    <ItemDetail>
      <UnitPrice>
        <Money currency="EUR">125.00</Money>
      </UnitPrice>
      <Description xml:lang="it">Prodotto A</Description>
      <UnitOfMeasure>EA</UnitOfMeasure>
    </ItemDetail>
  </ItemOut>
</OrderRequest>

Se questo scenario minimo non viene gestito in modo robusto, il resto del progetto va fermato e corretto prima di aggiungere casi più ricchi.

Sequenza visiva del flusso

Buyer Procurement            F-Merchant                   ERP / OMS
      |                           |                           |
      | ---- OrderRequest ------> |                           |
      |                           | -- crea ordine interno -->|
      |                           | <- esito / ID interno ----|
      |                           |                           |
      | <--- stato tecnico / ack? |                           |
      |                           |                           |

Lettura pratica del diagramma:

1. il buyer trasmette l’OrderRequest a F-Merchant;
2. F-Merchant valida, mappa e crea l’ordine applicativo;
3. l’ordine viene propagato a ERP o OMS;
4. i sistemi downstream restituiscono l’esito utile per proseguire con conferme ed evasione.

Dal Carrello all’Ordine

Il percorso che porta alla generazione di un Ordine di Acquisto attraversa tre passaggi distinti:

1. PunchOutOrderMessage: Al termine della sessione di shopping sul sito del fornitore, il carrello viene restituito al sistema e-procurement dell’acquirente sotto forma di PunchOutOrderMessage. In questa fase non esiste ancora alcun impegno formale.
2. Purchase Requisition (Richiesta di Acquisto): Il carrello viene convertito in una richiesta interna, sottoposta al flusso di approvazione aziendale (limiti di spesa, autorizzazioni gerarchiche, verifiche di budget).
3. OrderRequest (Ordine di Acquisto): Solo dopo l’approvazione finale il sistema genera e trasmette l’OrderRequest al fornitore.

L’OrderRequest rappresenta il primo documento che impegna formalmente l’acquirente al pagamento. Tutto ciò che precede — il carrello e la richiesta di acquisto — ha valore esclusivamente interno e non vincola in alcun modo verso il fornitore.

Note di implementazione F-Merchant

Nel contesto F-Merchant, l’ordine in ingresso deve essere tradotto senza ambiguità in un ordine applicativo e poi, di norma, inoltrato a ERP o sistemi di fulfillment. I punti critici sono:

• deduplicazione degli ordini in caso di retry o ritrasmissione buyer;
• mantenimento del legame tra orderID buyer e ordine interno F-Merchant;
• mapping delle righe tramite SupplierPartID o codici equivalenti stabili;
• normalizzazione di quantità, unità di misura, valuta e imposte;
• separazione tra dato ricevuto e dato eventualmente ricalcolato internamente.

Una buona integrazione non si limita a “creare un ordine”: deve anche dimostrare tracciabilità tra documento ricevuto, ordine interno e movimento ERP.

Mapping minimo consigliato

Errori comuni e cause tipiche

Test minimi consigliati

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

1. ricezione di un ordine new con una riga valida;
2. ricezione di un ordine multi-riga con quantità e prezzi corretti;
3. ordine con SKU sconosciuto e gestione del rifiuto o dell’eccezione;
4. retry dello stesso orderID per verificare la deduplica;
5. aggiornamento type="update" con modifica quantità;
6. cancellazione type="delete" con verifica di propagazione verso ERP o OMS.

Gestione delle Modifiche

L’attributo type dell’elemento OrderRequestHeader consente di gestire l’intero ciclo di vita dell’ordine senza dover ricorrere a comunicazioni fuori sistema:

• new: Identifica un ordine originale, trasmesso per la prima volta al fornitore.
• update: Indica una modifica a un ordine già emesso. Le casistiche più comuni includono il cambio di quantità su una riga, l’aggiunta di nuovi articoli o l’aggiornamento dell’indirizzo di spedizione.
• delete: Richiede la cancellazione completa dell’ordine. Il fornitore, una volta ricevuto il messaggio, è tenuto a interrompere l’evasione.

Grazie a questo meccanismo, ogni variazione viene tracciata in modo strutturato e resta collegata all’ordine originario tramite il campo orderID.

Collegamento ai Contratti Quadro

Quando l’ordine fa riferimento a un Contratto Quadro (Master Agreement), l’elemento MasterAgreementIDInfo all’interno dell’OrderRequestHeader permette di collegare la riga d’ordine al contratto di riferimento. Questo consente al sistema e-procurement di monitorare automaticamente la spesa effettiva rispetto al valore pattuito nell’accordo, offrendo piena visibilità sul consumo del budget contrattuale.