Monitoraggio in tempo reale (Accettazione, Backorder, Spedizione).

Conferme e Stato Ordine

Una volta ricevuto un Ordine di Acquisto (OrderRequest), il fornitore deve inviare aggiornamenti sullo stato di avanzamento. Questo garantisce trasparenza e permette all’acquirente di monitorare le date di consegna.

Supporto in F-Merchant: parte naturale dei progetti in cui l’acquirente richiede visibilità post-ordine e aggiornamenti operativi affidabili.

Direzione tipica: da F-Merchant o dal gestionale del fornitore verso il buyer o il network procurement.

Chi deve leggerla: integration developer, operations team, customer service B2B, ERP team che governa evasione e stato ordine.

Sistemi coinvolti di solito: F-Merchant, ERP del fornitore, sistemi logistici o WMS, piattaforma procurement del buyer.

Il documento chiave in questa fase è la ConfirmationRequest.

Checklist minima di implementazione

Per gestire correttamente conferme e stato ordine servono almeno:

• correlazione affidabile tra conferma e orderID/lineNumber originari;
• regole condivise per stati supportati: accettato, parziale, backorder, rifiutato;
• date stimate e quantità confermate coerenti con i sistemi di evasione;
• instradamento dal sistema operativo o ERP verso F-Merchant e poi verso il buyer;
• gestione distinta tra conferma d’ordine e avviso di spedizione;
• tracciabilità delle revisioni se lo stato cambia più volte.

Se lo stato ordine non resta sincronizzato con i sistemi operativi reali, la conferma perde valore anche se il documento XML è formalmente corretto.

Tipi di Conferma

La conferma può avvenire a diversi livelli:

1. Conferma dell’intero ordine (Accettazione totale): Tutti gli articoli sono accettati e verranno evasi.
2. Backorder (Ordini Arretrati): Alcuni articoli non sono immediatamente disponibili e la loro consegna sarà posticipata.
3. Rifiuto (Rejection): L’ordine o specifiche righe vengono rifiutate (es. prezzo errato, prodotto fuori produzione).

Ulteriori documenti di stato includono gli avvisi di spedizione (ShipNoticeRequest), che informano l’acquirente del transito reale della merce.

Campi minimi richiesti

Per una conferma ordine utilizzabile in produzione, questi elementi sono normalmente indispensabili:

Una conferma troppo generica, senza riferimenti di riga e senza quantità/data, viene spesso accettata dal parser ma non è utile al processo operativo.

Esempio minimo valido di conferma

<ConfirmationRequest>
  <ConfirmationHeader noticeDate="2026-03-03T11:00:00+01:00" type="detail">
    <OrderReference orderID="PO-2026-00421" />
  </ConfirmationHeader>
  <OrderReference orderID="PO-2026-00421" />
  <ConfirmationItem quantity="2" lineNumber="1">
    <UnitOfMeasure>EA</UnitOfMeasure>
    <ConfirmationStatus type="accept" quantity="2" shipmentDate="2026-03-05">
      <UnitPrice>
        <Money currency="EUR">125.00</Money>
      </UnitPrice>
    </ConfirmationStatus>
  </ConfirmationItem>
</ConfirmationRequest>

Questo è il caso base: una riga confermata integralmente con data prevista di spedizione. Da qui si costruiscono i casi più complessi come backorder parziali o rifiuti.

Sequenza visiva del flusso

ERP / OMS                  F-Merchant                 Buyer Procurement
   |                           |                              |
   | -- stato evasione ------> |                              |
   |                           | -- ConfirmationRequest ----> |
   |                           |                              |
   |                           | -- ShipNoticeRequest ------> |
   |                           |                              |

Lettura pratica del diagramma:

1. ERP o OMS produce lo stato reale dell’ordine;
2. F-Merchant traduce lo stato in ConfirmationRequest;
3. quando la merce parte, il flusso può proseguire con ShipNoticeRequest;
4. il buyer aggiorna pianificazione e ricezione sulla base di questi messaggi.

Note di implementazione F-Merchant

Nel contesto F-Merchant, le conferme dovrebbero nascere da eventi reali di processo, non da testi manuali o aggiornamenti scollegati. Di norma bisogna allineare:

• ordine esterno buyer con ordine interno F-Merchant;
• riga cXML con riga ERP o OMS;
• quantità confermata con disponibilità e piano evasione reale;
• data promessa con date gestite in magazzino o logistica;
• motivo di eccezione con causali operative riusabili.

La criticità più comune è inviare una conferma positiva troppo presto e poi doverla correggere fuori processo. Meglio uno stato preciso e difendibile che una conferma “ottimistica” ma poco affidabile.

Mapping minimo consigliato

Errori comuni e cause tipiche

Test minimi consigliati

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

1. conferma positiva completa di un ordine con una riga;
2. conferma parziale con quantità inferiore all’ordinato;
3. backorder con data futura esplicita;
4. rifiuto di una riga con causale leggibile;
5. aggiornamento di stato successivo alla conferma iniziale;
6. separazione corretta tra ConfirmationRequest e ShipNoticeRequest.