
Indice
- Cosa gestisce SAP SD
- Componenti principali
- Ordini di vendita e controllo di disponibilità
- Determinazione dei prezzi e condizioni
- Spedizione
- Fatturazione, determinazione dei conti e imposte
- Gestione del credito
- Struttura organizzativa
- Cosa cambia su S/4HANA
- Punti di integrazione
- SD con MM
- SD con PP
- SD con FI
- Dove si inceppano le implementazioni SD
- Domande frequenti
SAP SD (Sales and Distribution) gestisce l'order-to-cash in SAP: offerta, ordine di vendita, consegna, fatturazione e passaggio alla finanza. Su S/4HANA cambia in modi che contano per l'ambito del progetto. I clienti diventano business partner, la gestione del credito passa a SAP Credit Management, i rebate passano ai contratti di condizione e la fatturazione registra direttamente nell'Universal Journal. Questa guida è per responsabili delle vendite operative, controller finanziari e project manager che devono sapere che cosa fa SD e dove si inceppa. La risposta breve sul secondo punto: dati anagrafici dei clienti, condizioni di prezzo, controllo di disponibilità e determinazione dei conti. Testi questi quattro elementi con dati reali prima del go-live.
In un rollout successivo a un'implementazione SAP completa, i passaggi dell'order-to-cash erano stati costruiti esattamente come progettati. Sulla mappa dei processi sembravano a posto. Nessuno aveva verificato come arrivassero dalla produzione gli aggiornamenti delle scorte.
Le vendite dicevano ai clienti cinque giorni. La produzione sapeva che ne servivano circa dieci.
Quel divario è costato più delle consegne in ritardo. È costato fiducia, e la fiducia è più difficile da ricostruire di un'impostazione di configurazione.
SD sta all'inizio della catena logistica. Trasforma l'interesse di un cliente in una fattura attraverso una catena di documenti:
- Richiesta: il cliente chiede prezzo o disponibilità
- Offerta: un'offerta formale di prezzo e consegna con un periodo di validità
- Ordine di vendita: il cliente si impegna, parte il controllo di disponibilità e viene confermata una data di consegna
- Consegna: il magazzino esegue prelievo e imballaggio; l'uscita merci riduce le scorte
- Fatturazione: viene creata la fattura insieme al relativo documento contabile
- Pagamento: la finanza compensa l'incasso rispetto alla partita aperta
Ogni documento fa riferimento a quello precedente. È quel flusso dei documenti a rendere tracciabile l'order-to-cash. Se la catena è pulita, si può risalire da ogni fattura alla richiesta originale. Se i documenti vengono creati fuori sequenza o aggirati, il reporting si rompe e arrivano le contestazioni.
- RichiestaPrezzo o disponibilità richiesti
- OffertaOfferta formale con una data di validità
- Ordine di venditaIl controllo di disponibilità conferma la data
- ConsegnaPrelievo, imballaggio, uscita merci
- FatturazioneFattura e documento contabile
- PagamentoLa finanza compensa la partita aperta
Ogni fattura è riconducibile alla richiesta originale
Fatto bene, quella catena elimina i passaggi manuali. Un cliente manifatturiero ha ridotto del 40% il proprio ciclo order-to-cash dopo il go-live di SD, soprattutto eliminando i passaggi di mano tra vendite, magazzino e finanza.
Ordini di vendita e controllo di disponibilità
L'elaborazione degli ordini di vendita è dove si concentra la maggior parte dello sforzo di configurazione di SD: tipi di ordine, categorie di posizione, schedulazioni e controllo di disponibilità.
L'available-to-promise (ATP) è l'elemento più critico per il business. Verifica se la data richiesta può essere rispettata con le scorte, i ricevimenti pianificati e gli impegni esistenti. Configurato bene, fa sì che le vendite dicano ai clienti ciò che il sistema può davvero garantire. Configurato male, fa sì che le vendite dicano ai clienti ciò che sperano di consegnare.
Nel rollout dell'apertura, nessuno aveva verificato come arrivassero dalla produzione gli aggiornamenti delle scorte. Le vendite promettevano date che lo stabilimento non era in grado di rispettare.
Determinazione dei prezzi e condizioni
La determinazione dei prezzi è la configurazione più sottovalutata in SD. Sembra semplice fino alla prima contestazione su una fattura.
La tecnica delle condizioni di SD gestisce prezzi di base, sconti cliente, scaglioni di volume, supplementi, trasporto e imposte. Ogni elemento è un tipo di condizione con una sequenza di accesso, e il record di condizione contiene il valore.
Il problema di prezzo più comune che vedo: condizioni di prezzo vecchie, rimaste dal go-live e mai aggiornate. Il business rinegozia uno sconto, nessuno aggiorna il record di condizione in SD, la fattura è sbagliata e la contestazione finisce nella contabilità clienti.
La governance dei prezzi è una decisione di processo, non di configurazione. Qualcuno deve occuparsi della manutenzione dei record di condizione.
Spedizione
L'elaborazione delle consegne copre prelievo, imballaggio e uscita merci. L'uscita merci è l'evento critico: registra la riduzione delle scorte, inserisce la consegna nella lista dei documenti da fatturare e registra la data di consegna effettiva. La determinazione del punto di spedizione e dell'itinerario controlla come vengono create le consegne. Le aziende con reti di distribuzione complesse la estendono con SAP Transportation Management (TM).
Fatturazione, determinazione dei conti e imposte
La fatturazione trasforma la consegna in una fattura e crea il documento contabile. La determinazione dei conti associa ogni posizione di fatturazione ai conti di ricavo, di imposta e agli altri conti di contabilità generale, in base all'organizzazione commerciale, ai gruppi di assegnazione conti di cliente e materiale e al tipo di condizione. Quando è sbagliata, la fattura registra sul conto sbagliato e la finanza lo scopre a fine mese.
La determinazione dell'imposta è altrettanto fragile. Dipende dalla classificazione fiscale del cliente, dalla classificazione fiscale del materiale e dal paese o dalla giurisdizione di consegna. Un'incongruenza può produrre una fattura senza imposta su una vendita imponibile, o con l'imposta su una vendita esente.
Gestione del credito
I controlli del credito bloccano o segnalano gli ordini che porterebbero un cliente oltre il proprio fido. Funziona solo se i fidi sono mantenuti. I fidi statici impostati al go-live smettono di avere significato man mano che cambiano i comportamenti di pagamento e i volumi.
Quando un fido scende sotto la dimensione normale degli ordini di un cliente, ogni ordine viene bloccato automaticamente. I team di vendita imparano allora a rimuovere i blocchi invece di chiedere una revisione del fido.
Questa non è gestione del credito. È un workaround.
Questi sono gli elementi della struttura di SD e a che cosa si collega ciascuno.
| Elemento della struttura | Scopo in SAP SD | Collegamento chiave |
|---|---|---|
| Organizzazione commerciale | Unità di vendita di livello più alto, responsabile di condizioni di vendita e responsabilità | Assegnata a una società in FI |
| Canale distributivo | Come i prodotti raggiungono il cliente (ingrosso, dettaglio, diretto) | Controlla prezzi, dati anagrafici e determinazione dei partner |
| Settore merceologico (division) | Gruppo di prodotti all'interno dell'organizzazione commerciale | Raggruppamento dei materiali per reporting e output |
| Area di vendita | Organizzazione commerciale, canale distributivo e settore merceologico insieme | Obbligatoria per ogni documento di vendita e ogni record cliente |
| Ufficio vendite | Unità commerciale geografica | Reporting regionale e determinazione dei partner |
| Gruppo di vendita | Team all'interno di un ufficio vendite | Responsabile sugli ordini |
| Punto di spedizione | Luogo da cui partono le merci | Collega SD alla gestione del magazzino e al trasporto |
| Divisione (plant) | Unità produttiva o fornitrice | Origine delle scorte, collegata al punto di spedizione |
L'area di vendita è l'unità operativa. I dati di vendita del cliente sono mantenuti per area di vendita e ogni documento di vendita viene creato in una di esse. Molte migrazioni inciampano qui: i record cliente legacy che non si mappano in modo pulito sulle aree di vendita richiedono una vera preparazione prima del caricamento.
Se si passa da ECC, queste sono le modifiche a SD da pianificare nell'ambito. Nella documentazione di S/4HANA SAP classifica quest'area sotto «Sales», anche se la maggior parte dei team continua a chiamarla SD.
- I clienti sono business partner. I dati anagrafici del cliente si gestiscono tramite il business partner con un ruolo cliente. In una conversione, l'integrazione cliente-fornitore va impostata prima che la conversione venga eseguita.
- La gestione del credito passa a SAP Credit Management. La gestione del credito di ECC (FI-AR-CR) non è disponibile in S/4HANA. SAP Credit Management (FIN-FSCM-CR) è il suo sostituto, quindi una conversione deve migrare dati e impostazioni del credito. Non è opzionale.
- I rebate passano ai contratti di condizione. L'elaborazione classica dei rebate di SD è sostituita da Settlement Management (gestione dei contratti di condizione). Le condizioni di rebate si applicano subito invece di essere ricostruite da un indice.
- Advanced ATP. L'advanced ATP di S/4HANA aggiunge allocazione dei prodotti, elaborazione dei backorder, conferma basata su alternative tra plant diversi, release for delivery e supply assignment. In S/4HANA Cloud queste funzioni rientrano nella licenza standard. On-premise richiedono una licenza dedicata una volta attivate.
- La fatturazione registra nell'Universal Journal. FI, CO e analisi della redditività condividono un'unica posizione in ACDOCA, il che elimina il lavoro di riconciliazione FI-CO di ECC. Il rovescio della medaglia: un errore di determinazione dei conti è una registrazione immediata sul conto sbagliato, visibile a livello di singola posizione.
- Riconoscimento dei ricavi. Per i contratti multi-elemento, gli abbonamenti o i servizi a lungo termine ai sensi dell'IFRS 15, SAP Revenue Accounting and Reporting sostituisce la logica di differimento custom che molti programmi ECC avevano costruito. Ha una licenza separata e va progettato prima del go-live, non scoperto a fine anno.
Il Clean Core cambia il modo in cui si gestisce la personalizzazione di SD. Sul public cloud il codice custom nel core non è possibile. Sul private cloud e on-premise è possibile, ma rende più difficile ogni upgrade. La maggior parte delle vecchie routine Z di determinazione dei prezzi si può sostituire con tipi di condizione standard, formule e BAdI. Ciò che resta davvero va in un'estensione side-by-side su SAP BTP. La mia guida al Clean Core tratta la decisione.
SAP SD collega la promessa di vendita alla realtà operativa. Quando questo collegamento è sbagliato, il cliente se ne accorge per primo.
SD con MM
Il controllo di disponibilità legge le scorte da MM e l'uscita merci registra il movimento di magazzino. Se i dati di inventario sono sbagliati, i risultati dell'ATP non sono affidabili. Se l'uscita merci fallisce perché le scorte non sono davvero nel punto di spedizione, la consegna non può essere completata e la fatturazione si blocca. Tenga entrambi allineati con i dati anagrafici e con la disciplina: nessuna rettifica manuale delle scorte che aggiri le registrazioni standard.
SD con PP
Negli scenari make-to-order, un ordine di vendita può guidare direttamente la produzione, quindi la data confermata diventa un impegno sostenuto da un ordine di produzione. Il gruppo strategia nell'anagrafica materiale controlla come interagiscono ordini di vendita e previsioni. Se è impostato male, si sommano invece di compensarsi, l'elaborazione della pianificazione sovrastima la domanda e ne consegue la sovrapproduzione. La mia guida a SAP PP copre il lato della pianificazione.
SD con FI
Il documento di fatturazione è l'interfaccia. Ogni fattura crea un documento contabile che registra ricavi, imposta e la partita aperta del cliente nell'Universal Journal. Le condizioni di pagamento nell'anagrafica cliente determinano la data di scadenza. Quando le vendite negoziano condizioni senza dirlo alla finanza, il sistema applica condizioni che la finanza non ha mai concordato.
Se il design di SD tratta tutti i ricavi come riconosciuti alla fatturazione e i contratti dicono altro, l'adeguamento successivo è costoso. Concordi il riconoscimento dei ricavi con la finanza prima che il design venga approvato. Per il lato finanziario dell'integrazione, veda la mia guida a SAP FICO.
Quattro punti di rottura causano la maggior parte dei problemi dopo il go-live.
Anagrafica cliente non pronta. Ogni campo conta a valle. Una classificazione fiscale mancante significa imposta sbagliata. Condizioni di pagamento mancanti significano che FI non può calcolare le scadenze. Condizioni di spedizione mancanti compromettono la schedulazione delle consegne. I volumi sono più grandi e i dati di origine peggiori di quanto il piano presuma, e la pulizia richiede decisioni di business. Parta presto e la tratti come un workstream di business, non come un caricamento tecnico. Il mio pezzo sul perché la migrazione dei dati SAP fallisce ne descrive il metodo.
Condizioni di prezzo non mantenute. Le condizioni del go-live che nessuno rivede diventano contestazioni sulle fatture entro il primo anno.
Controllo di disponibilità scollegato dalla realtà. Un ATP che legge dati obsoleti produce promesse che il business non può mantenere. Lo validi con scenari reali di produzione e di scorte, non con i dati di test puliti usati nei test unitari.
Lacune nella determinazione dei conti scoperte dopo il go-live. Testi con il piano dei conti, i codici IVA e i gruppi merci effettivi. Codici IVA non corrispondenti possono bloccare gli ordini o far scoppiare contestazioni sulle fatture prima che qualcuno si accorga di cosa non va.
La tabella è la checklist che ripercorrerei prima dell'approvazione dell'UAT.
| Rischio | Impatto | Mitigazione |
|---|---|---|
| Anagrafica cliente incompleta | Errori nelle fatture, consegne non riuscite, lacune nelle registrazioni FI | Avviare presto il workstream dati; definire i campi obbligatori per area di vendita prima della migrazione |
| Condizioni di prezzo obsolete | Contestazioni sulle fatture, ricavi errati | Nominare un responsabile dei record di condizione e un ciclo di revisione al go-live |
| ATP scollegato da PP o MM | Promesse di consegna inaffidabili | Testare l'ATP con scenari di pianificazione reali prima dell'approvazione dell'UAT |
| Lacune nella determinazione dei conti | Ricavi registrati sui conti sbagliati | Testare con il piano dei conti reale e l'insieme completo dei codici IVA |
| Sblocchi del credito come routine | Esposizione non controllata, contestazioni sui crediti | Imporre le revisioni dei fidi; monitorare gli sblocchi manuali nei primi 90 giorni |
| Output non testato | Fatture e bolle di consegna non inviate automaticamente | Testare ogni tipo di output con instradamento reale di stampa ed e-mail prima del go-live |
| Condizioni di pagamento disallineate | Scadenze errate, errori nelle previsioni di cassa | Concordare le condizioni tra vendite e finanza prima di caricare i dati cliente |
Se il team vendite rimuove di routine i blocchi del credito invece di chiedere una revisione, lo risolva nei primi novanta giorni, prima che l'abitudine si consolidi.
Che cos'è SAP SD e che cosa fa?
SAP SD (Sales and Distribution) gestisce l'order-to-cash: richieste, offerte, ordini di vendita, consegne, fatturazione e passaggio alla contabilità finanziaria. Il suo flusso dei documenti collega ogni passaggio a quello precedente, così ogni fattura può essere ricondotta all'ordine originale. Si integra con MM per scorte e uscita merci, con PP per make-to-order e disponibilità e con FI per ricavi, imposte e crediti.
Qual è la struttura organizzativa in SAP SD?
L'unità operativa è l'area di vendita: un'organizzazione commerciale, un canale distributivo e un settore merceologico insieme. Ogni documento di vendita viene creato in un'area di vendita e i dati di vendita del cliente sono mantenuti per area di vendita. Uffici vendite e gruppi di vendita stanno sotto, per reporting e responsabilità. Sul lato logistico, punti di spedizione e divisioni (plant) determinano da dove partono le merci. Imposti bene la struttura prima di caricare i dati cliente, perché cambiarla dopo significa ricaricare i dati.
Come funziona la determinazione dei prezzi in SAP SD?
La determinazione dei prezzi usa la tecnica delle condizioni. Ogni elemento di prezzo è un tipo di condizione, una sequenza di accesso decide quale record di condizione si applica e uno schema di determinazione dei prezzi combina in ordine i tipi di condizione. La maggior parte delle contestazioni sui prezzi risale a record di condizione non aggiornati quando le condizioni commerciali sono cambiate, non a errori di configurazione.
Che cos'è l'advanced ATP in SAP S/4HANA?
L'advanced available-to-promise (aATP) è il controllo di disponibilità di S/4HANA. Oltre al controllo di disponibilità base dei prodotti, aggiunge allocazione dei prodotti, elaborazione dei backorder, conferma basata su alternative tra plant diversi, release for delivery e supply assignment. Queste funzioni sono incluse in S/4HANA Cloud e richiedono una licenza dedicata on-premise una volta attivate. Le usi dove l'offerta è vincolata o dove contano le regole di allocazione. Per supply chain stabili, un controllo base ben configurato spesso basta.
Come si integra SAP SD con la contabilità finanziaria?
Attraverso il documento di fatturazione. Rilasciare un documento di fatturazione alla contabilità crea una scrittura contabile per ricavi, imposta e partita aperta del cliente. La determinazione dei conti decide i conti di contabilità generale in base all'organizzazione commerciale, ai gruppi di assegnazione conti e al tipo di condizione. L'imposta dipende dalle classificazioni fiscali di cliente e materiale. Le condizioni di pagamento nell'anagrafica cliente fissano la scadenza. Nei casi IFRS 15, SAP Revenue Accounting and Reporting differisce e riconosce i ricavi nel tempo.
Cosa cambia in SAP SD passando da ECC a S/4HANA?
I clienti diventano business partner. La gestione del credito passa da FI-AR-CR a SAP Credit Management, che è obbligatorio. L'elaborazione dei rebate è sostituita dai contratti di condizione in Settlement Management. Diventa disponibile l'advanced ATP e la fatturazione registra nell'Universal Journal. Pianifichi tutto nell'ambito fin dall'inizio, perché ognuno di questi punti richiede configurazione, migrazione dei dati e test.
Quali sono gli errori più comuni nelle implementazioni SAP SD?
Ne ricorrono cinque. Sottovalutare i dati anagrafici dei clienti. Lasciare le condizioni di prezzo senza un responsabile dopo il go-live. Testare l'ATP solo con dati puliti. Testare la determinazione dei conti con dati semplificati. Non testare l'output end to end. L'ultimo è facile da trascurare. Quando le fatture non partono in automatico, qualcuno inizia a stamparle a mano, e il workaround diventa permanente.
Il prossimo passo
Sta gestendo un programma ERP in questo momento?
Se questo articolo tocca un programma che sta seguendo in questo momento, una conversazione di 30 minuti di solito porta più lontano di un'altra settimana di analisi interna.




