Al giorno d'oggi i negozi online stanno diventando sempre più popolari nel modo in cui i clienti vedono lo shopping e sembrano un "must be" per le aziende. Un buon negozio online o un'app mobile per la vendita può essere molto redditizio per un'azienda, un marchio e, d'altro canto, significa una diversificazione dei canali di vendita. I negozi fisici combinati con piattaforme online e canali mobili rappresentano una sfida per integrare le vendite omnicanale come avere lo stesso prezzo di vendita, gestire promozioni/bonus acquisti o infine disponibilità di magazzino. Tutti questi aspetti ci portano alla domanda: quale potrebbe essere il modo migliore per integrare il tuo e-shop con SAP?
Un po’ di teoria…
SAP CAR Omnichannel Article Availability and Sourcing (OAA) è un servizio per supportare l'integrazione per i rivenditori nell'area dell'e-commerce (piattaforme di e-commerce, e-shop, ecc.). Come indica il nome, la soluzione fornisce informazioni sulla disponibilità degli articoli in base a sequenze di fonti definite dall'azienda e supporta l'elaborazione del carrello degli acquisti. Fondamentalmente, consente al sistema connesso di leggere le fonti, la loro disponibilità e creare una prenotazione temporanea successivamente controllando la disponibilità del carrello del cliente.
Il tipico processo di vendita online
Ad esempio, ho preso il negozio online Ikea (non so se Ikea utilizzi SAP o qualsiasi altro sistema e come avvenga l'integrazione, qui è solo un esempio di negozio online). Il processo per il Cliente sembra essere abbastanza semplice. Nella prima fase il Cliente viene informato sul margine di acquisto online e poi sull'indicatore di disponibilità nei negozi (penso che in passato fosse anche possibile vedere l'esatto livello delle scorte in negozio).
Fonte: IKEA.com
Successivamente il Cliente seleziona la modalità di consegna (clicca e ritira, clicca e spedisci), l'indirizzo e l'ora di consegna, il metodo di pagamento e il processo sono terminati per il Cliente.
Fonte: IKEA.com
Dal punto di vista del sistema, il processo di vendita è più complesso e altrimenti sono necessari alcuni passaggi, con una spiegazione più dettagliata di seguito.
Indicatori di stock approssimativi: al punto di ingresso per le vendite online. Il sistema informa il Cliente sulla disponibilità generale del prodotto nei negozi per lo scenario clicca e ritira o per la consegna in caso di scenario clicca e spedisci.
Calcolo dettagliato della disponibilità: il sistema presenta al Cliente informazioni accurate sulla disponibilità del prodotto in negozio o in consegna.
Ogni tipo di fonte di consegna ha un modo diverso di calcolare le informazioni sulla disponibilità:
- Centro di distribuzione: la chiamata RFC viene eseguita da CAR verso S/4 per eseguire la funzione ATP per una serie di articoli. In caso di soluzione online di terze parti, Idoc può essere utilizzato per l'integrazione.
- Stock del venditore: lo stock dell'articolo consegnato dal venditore viene caricato con il servizio Odata e archiviato nelle tabelle OAA_VEND_STOCK_H/I sul lato S/4. Se il fornitore è in sequenza di approvvigionamento e non è disponibile il sistema informativo sulle scorte, presuppone una disponibilità illimitata.
- Negozio: si tratta di un unico tipo di sourcing in cui le informazioni sulla disponibilità risiedono solo su SAP CAR (la maggior parte di esse è stata precedentemente migrata con SLT). Il sistema utilizza la vista predefinita InventoryVisibilityWithSalesOrderReservedQuantity (prende in considerazione scorte illimitate, transazioni non elaborate presso CAR) per calcolare la disponibilità.
Selezione degli scenari di consegna supportata nello standard:
- Clicca e spedisci: il cliente riceverà la consegna all'indirizzo richiesto
- Clicca e ritira: il cliente ritirerà la merce presso il negozio.
Souring – il sistema ricerca in background le fonti di consegna ottimali per il carrello e lo scenario di consegna selezionato.
Prenotazione temporanea: il sistema sta effettuando una prenotazione temporanea per il carrello degli acquisti di un Cliente.
Configurazione di sistema
Poiché la soluzione OAA è distribuita su un numero di personalizzazioni del sistema, è necessario eseguire in CAR e S/4 e quindi configurare la soluzione (memorizzata in CAR) tramite Fiori.
In SAP CAR la personalizzazione viene eseguita nel nodo CAR – Omnichannel Article Availability and Sourcing (OAA)
Modalità canale di vendita e modalità profilo OAA.
Esistono due modi per eseguire la personalizzazione necessaria. Il primo: la modalità profilo OAA, un po' più vecchia e la maggior parte delle configurazioni come la definizione della rete di sourcing vengono eseguite all'interno dell'implementazione Badi. Ciò significa che l'implementazione di Badi è stata eseguita nel modo in cui legge la tabella Z oppure è necessario modificare un codice ogni volta che si desidera apportare modifiche alla determinazione della fonte. Il secondo è molto più flessibile poiché nella personalizzazione di CAR si definisce solo l'ID del canale di vendita e la restante configurazione della soluzione viene eseguita tramite le app Fiori. Inoltre, secondo la documentazione solo questa versione è supportata in ambiente S/4. Qui mi concentrerò solo sulla modalità Canale di vendita.
In SAP S/4 la configurazione è correlata all'area di controllo della disponibilità dello snapshot ATP per gli articoli consegnati da DC. Questa configurazione viene eseguita nel nodo SD – Controllo disponibilità con logica ATP o Contro pianificazione – Vendita al dettaglio: disponibilità e approvvigionamento articoli multicanale.
Utilizzare innanzitutto l'opzione “Definisci connessioni di sistema” per impostare la connessione RFC utilizzata per inviare i risultati del controllo ATP alla CAR. Il motivo è che l'ATP può essere eseguito per un lungo elenco di articoli e, nonostante l'ottimizzazione, può comunque essere un'operazione di lunga durata. I risultati dello snapshot ATP in caso di integrazione con la piattaforma online in cui non viene utilizzato SAP CAR vengono distribuiti con Idoc al sistema di destinazione. In questo caso la personalizzazione contiene dettagli sul sistema ricevente, porta, ecc. dell'Idoc e viene attivata con la transazione OAA_GENERATE_ATP_SNAPSHOT per il calcolo ATP. Il secondo passaggio per la replica dello snapshot ATP consiste nel "Definire i profili di parallelizzazione ATP per gli articoli DC" in cui l'ID di connessione della colonna definisce la modalità di gestione dei dati del risultato ATP (RFC di nuovo su CAR o Idoc).
Per soddisfare le esigenze del Cliente, l'azienda, invece di o come ulteriore necessità, deve utilizzare i beni acquistati dal proprio fornitore. Come accennato in precedenza, la quantità che il fornitore può consegnare in una determinata data viene archiviata nel backend nelle tabelle OAA_VEND_STOCK_H/I dopo che la replica ha avuto luogo con i servizi Odata (servizio OData per il caricamento delle informazioni sullo stock del fornitore S/4: /sap/ opu/odata/sap/OAA_VENDOR_STOCK_SRV)
Configurazione della soluzione Fiori
La personalizzazione eseguita in CAR (non tanto, solo l'ID canale di vendita) è una base per la configurazione della soluzione con le app Fiori. È importante distinguere che esistono app separate per la configurazione in cui il sistema di destinazione è SAP Retail e SAP S/4. Le app presentate di seguito riguardano l'integrazione S/4 e la sequenza in cui devono essere eseguite.
Gestisci origini – SAP S/4HANA
Questa app viene utilizzata solo per impostare le capacità delle operazioni di prelievo e imballaggio. Ogni transazione online se il sourcing indica DC o Store richiede il tempo necessario per espletarla. Se non vogliamo essere sovraccarichi, c'è un'opzione per impostare il numero massimo di transazioni che DC o Store possono eseguire al giorno. Se utilizzi il fornitore come fonte o non desideri utilizzare i limiti di capacità, questo passaggio è facoltativo.
Il panorama della soluzione è distribuito su un numero di sistemi. A parte il frontend che può essere SAP Commerce, la maggior parte dei dati proviene da S/4 e la logica di elaborazione risiede su SAP CAR.
Gestire le reti di sourcing SAP S/4HANA
In questa app Fiori imposti un elenco di potenziali fonti per i tuoi prodotti. Ciò che è importante ricordare è che la sequenza delle fonti aggiunte non ha importanza in questo caso poiché è disponibile solo l'elenco delle fonti che possono essere utilizzate per evadere l'ordine.
Come presentato sopra, utilizzo tutte le potenziali fonti di fornitura per i clienti in questa parte del paese ma, come menzionato prima, questo elenco non significa da dove e come vengono evasi gli ordini.
Gestire le strategie di approvvigionamento
Questa è la parte più importante della configurazione della soluzione dell'app Fiori. Poiché le fonti sono già state definite in questa app, decidiamo quali utilizzare, quando e come.
Con il supporto di tutte le possibili variazioni delle fonti di consegna che vorrei avere: prima dal Negozio se l'articolo è disponibile lì, poi da DC e poi al più tardi dalla consegna dal Venditore (rifornimento di terze parti).
La configurazione contiene un paio di passaggi ben descritti nella guida dell'applicazione. In generale il sistema deve leggere le potenziali fonti, leggerne la disponibilità, ordinarle, filtrarle (non utilizzato qui ma l'opzione potrebbe essere ad esempio una distanza dalla fonte al cliente ecc.) e alla fine decidere la logica aziendale su come effettuare la consegna.
Ciò che personalmente mi piace di questa configurazione e in generale della soluzione OAA è la flessibilità per le estensioni. Se vuoi ad esempio aggiungere la tua logica relativa al filtraggio in base ai costi di spedizione devi creare una classe che implementi una rispettiva interfaccia abap e con il metodo dei metadati puoi raccogliere i parametri di input direttamente nell'app Fiori.
Gestire i canali di vendita
Il passaggio finale della configurazione consiste nel combinare tutti questi singoli elementi con l'ID del canale di vendita per:
- Rete di approvvigionamento: fonti dove verificare l'articolo.
- Strategia di approvvigionamento: come evadere l'ordine in base alla rete di approvvigionamento.
Esempio:
Utilizzerò due articoli con i seguenti livelli di stock e disponibilità.
Articolo 1: OAA_ART_T1
Disponibile nel negozio a Liverpool con una quantità di 15 PC e quindi le consegne avvengono dallo stock attuale DC di 10 PC, quindi rifornimento con RLT: 2d tempo di consegna pianificato e 1d tempo GR.
Articolo 2: OAA_ART_T2
Disponibile nel negozio di Leeds con una quantità di 5 PC, quindi le consegne avvengono dallo stock attuale DC di 15 PC, quindi rifornimento con RLT: 1d tempo di consegna pianificato e 1d tempo GR. Il venditore può consegnare 25 PC fino al 01/12.
Passaggio 1: recupera i dati di disponibilità su CAR
In CAR, eseguo report (nel sistema live è meglio avere un lavoro in background) /OAA/ATP_SNP_CALC per recuperare informazioni sulla disponibilità come snapshot ATP. Per generare informazioni sulla disponibilità per gli articoli DC, il sistema attiva l'esecuzione ATP parallelizzata in S/4 e per le informazioni sulla disponibilità degli articoli del fornitore il sistema legge le informazioni sulle scorte del fornitore dalle tabelle (tabelle OAA_VEND_STOCK_H/I) caricate in anticipo con i servizi Odata su S/4.
Risultato dell'esecuzione del report di replica dello snapshot ATP (/OAA/ATP_SNP_CALC) presentato di seguito:
Interessante è l'ultima riga in cui la quantità di ATP sta raggiungendo un numero illimitato. Questo perché a S/4 la procedura ATP viene calcolata considerando RLT dell'articolo.
Passaggio 2: inviare le informazioni sugli indicatori grezzi delle scorte (RSI) al negozio
Un indicatore di stock approssimativo (RSI) è un'indicazione visiva o testuale se un articolo è disponibile per l'acquisto o la consegna senza mostrare l'esatta quantità disponibile. RSI viene popolato con l'uso di Idoc attivato con il report /OAA/ATP_RSI_GENERATION_SC. Poiché le informazioni sull'indicatore RSI dipendono molto dai requisiti aziendali, lo standard controlla solo se esiste almeno una fonte con quantità disponibile per determinarne il valore. Per implementare la tua logica usa badi: /OAA/BADI_ATP_RSI_GENERATION.
Nell'Idoc utilizzato per distribuire informazioni sull'indicatore delle scorte grezze (RSI), ogni segmento contiene informazioni sulla disponibilità con enfasi sul campo ROUGH_STOCK_VALUE utilizzato per il valore di rappresentazione dell'indicatore RSI.
Passaggio 3: disponibilità dettagliata
Per visualizzare la disponibilità dettagliata dell'articolo per fonte viene utilizzato il servizio web.
L'approvvigionamento, la disponibilità e le prenotazioni temporanee sono tutti basati su servizi web. Maggiori dettagli sulla struttura dei messaggi si trovano nella nota 2841700 e una bella documentazione sui servizi web è disponibileQui
Indirizzo del servizio:
Esempio di recupero della disponibilità attuale di OAA_ART_T2 nel negozio 04.
Passaggio 4: approvvigionamento
Questo passaggio dirà la verità sulla disponibilità del carrello di spedizione, sulle potenziali fonti e consegne, ecc. Qui dividerei i test in tre scenari:
- Articolo singolo OAA_ART_T1 con quantità 12 PC (il negozio effettuerà una consegna)
- Articolo singolo OAA_ART_T2 con quantità 7PC (DC effettuerà una consegna)
- Entrambi gli articoli in un unico carrello con quantità T1 – 10 PC e T2 – 15 PC
Indirizzo del servizio:
Risultato per il caso 1:
Per quantità superiori a 15 PC non è possibile determinare la fonte.
Risultato per il caso 2:
Per quantità superiori a 15 PC viene determinato un fornitore esterno.
Risultato per il caso 3:
Se si aumenta la quantità dell'articolo da 1 a 12, il sistema PC non è in grado di determinare l'origine nonostante la quantità sia disponibile. Il motivo è che è stata richiesta una consegna singola in Gestisci strategie di approvvigionamento per la configurazione aziendale.
Passaggio 6: prenotazione temporanea
Nell'integrazione standard con SAP Commerce, CAR crea una prenotazione temporanea interna non appena viene effettuato l'approvvigionamento in cassa. Questo passaggio riduce la quantità disponibile per l'approvvigionamento. Il cliente crea l'ordine di vendita (in S/4) in base al carrello degli acquisti, quindi la prenotazione temporanea viene rimossa seguita dalla diminuzione della disponibilità ATP dovuta all'ordine effettuato. Nell'integrazione standard la prenotazione temporanea viene creata a livello di articolo e quando viene eseguito un approvvigionamento. La sincronizzazione tra l'ordine S/4 e la prenotazione temporanea viene effettuata tramite il campo del timestamp di sincronizzazione. Poiché non tutte le prenotazioni del cliente terminano con l'ordine di vendita, è disponibile un report per eliminare le prenotazioni temporanee obsolete /OAA/ATP_RESV_DELETION.
Indirizzo del servizio per creare una prenotazione:
Report per verificare la configurazione – molto utile.
Controllare la nota SAP "2806767 – Verifica dell'installazione e della configurazione del sistema per OAA" che contiene il codice per il report /OAA/CHECK_SYSTEM_SETUP. Questo è uno strumento molto utile che consente di verificare la configurazione dello scenario progettato in tutti i sistemi.