Integrazione Eshop con SAP Business One: flussi, requisiti e verifiche

Colleghiamo l'Eshop a SAP Business One con un flusso specifico e l'interfaccia disponibile nell'installazione. In SAP Business One l'ordine deve essere collegato a Business Partner, Item e al ciclo concordato dei documenti commerciali. L'Eshop non deve trattare consegna, fatturazione e annullamento come semplici modifiche di uno stato generico.

In SAP Business One l'ordine deve essere collegato a Business Partner, Item e al ciclo concordato dei documenti commerciali. L'Eshop non deve trattare consegna, fatturazione e annullamento come semplici modifiche di uno stato generico. Il progetto usa le azioni operative disponibili di Service Layer e conserva la relazione tra evento esterno e documenti SAP. Il responsabile SAP definisce serie, magazzini, campi richiesti e quando un processo è operativamente completo.

Service Layer fornisce un'interfaccia per dati e servizi di Business One. Il riferimento ufficiale raccomanda OData v4 come protocollo principale da FP2405 e definisce v3 obsoleto, pur mantenendolo per compatibilità. Business One non è S/4HANA. Endpoint, oggetti, configurazione e flusso operativo sono diversi. Neppure Service Layer è funzionalmente identico in ogni aspetto a DI API.

Un distributore di ricambi registra un acquisto B2B come ordine di vendita. Gli articoli corrispondono all'Item master e l'acquirente al Business Partner corretto. Se viene consegnata solo parte della quantità, l'Eshop viene aggiornato secondo i documenti confermati, non con un'indicazione generale di spedizione arbitraria. Una richiesta di annullamento viene esaminata nella fase in cui si trova l'ordine ed eseguita soltanto tramite una gestione consentita. L'associazione tra ordine e documenti successivi viene conservata per riconciliazione e assistenza.

Uno scenario critico si presenta quando si tenta un annullamento come semplice modifica di campo anziché con la gestione operativa appropriata. Conserviamo riferimento esterno e ID di destinazione confermato prima di ripetere l'azione. Distinguiamo fallimento dell'accesso, rifiuto operativo e risultato incerto. L'operatore deve poter esaminare il record pertinente e ripristinare lo stato senza ripetere passaggi completati. Concordiamo quali campi compaiano nei log e chi gestisca le attività in sospeso.

Verifichiamo creazione dell'ordine, annullamento supportato e associazione corretta del documento successivo. Per ogni caso documentiamo dati iniziali attesi, record di destinazione e stato visto dal cliente. Aggiungiamo un errore di autorizzazione e un'interruzione della risposta. Ripetiamo un evento già confermato e verifichiamo che il risultato operativo non cambi. Il verbale di accettazione definisce il team responsabile e le prove necessarie per chiudere una discrepanza.

Lo studio iniziale conferma: Service Layer attivo e accessibile nell'installazione; accordo sulla versione OData e sull'utente autorizzato; responsabile SAP per oggetti e regole commerciali. Prima della produzione documentiamo la mappatura del flusso Articoli/clienti SAP → mappatura Eshop → Checkout → ordine di vendita SAP → Conferma → consegna/stato secondo accordi. Definiamo responsabilità per rinnovo degli accessi, monitoraggio e correzioni. Una modifica alla configurazione del prodotto o alla regola operativa concordata attiva una nuova verifica mirata. Partiamo da questo flusso specifico e aggiungiamo un altro canale dopo averne chiarito responsabilità e scenari di accettazione.