Il Suo template dei dati per il processo Order-to-Cash: fatturazione
Il Suo template dei dati per il processo Order-to-Cash: fatturazione
- Attributi consigliati da raccogliere
- Attività chiave da monitorare
- Indicazioni per l’estrazione dei dati da SAP S/4HANA
Attributi del processo Order-to-Cash: fatturazione
| Nome | Descrizione | ||
|---|---|---|---|
| Numero fattura InvoiceNumber | Identificativo univoco di un documento di fatturazione, utilizzato come identificativo principale del caso nel processo di fatturazione. | ||
| Descrizione Il numero della fattura, denominato in SAP numero del documento di fatturazione, identifica in modo univoco ogni transazione di fatturazione. È la chiave centrale che collega tutte le attività correlate, dalla creazione e registrazione della fattura alla ricezione e riconciliazione del pagamento. Nel Process Mining, questo attributo è essenziale per associare gli eventi ai casi. Tutti gli eventi con lo stesso numero di fattura vengono raggruppati in un’unica istanza di processo, consentendo un’analisi completa, dall’inizio alla fine, del ciclo di vita di ogni fattura. È così possibile monitorare i tempi di ciclo, individuare le deviazioni e analizzare il percorso di ciascuna fattura. Perché è importante È l’identificativo fondamentale che collega tutte le attività di fatturazione correlate in un unico caso e rende possibile l’analisi del processo dall’inizio alla fine. Dove reperirli Tabella SAP: VBRK, campo: VBELN Esempi 900012349000567890009012 | |||
| Nome attività ActivityName | Nome dell’attività aziendale o dell’evento che si è verificato nel processo di fatturazione, ad esempio «Fattura generata» o «Pagamento ricevuto». | ||
| Descrizione Il nome dell’attività descrive una fase o una tappa specifica del ciclo di fatturazione. Le attività vengono ricavate da diverse fonti di dati SAP, come i codici di transazione, le modifiche allo stato dei documenti o specifiche voci di registro, per ricostruire il flusso sequenziale del processo. Analizzare la sequenza e la frequenza di queste attività è il fulcro del Process Mining. Consente di visualizzare la mappa del processo, individuare le varianti più e meno frequenti, rilevare i colli di bottiglia tra le fasi e misurare la frequenza delle attività che non aggiungono valore, come le rilavorazioni o gli annullamenti. Perché è importante Questo attributo definisce le fasi del processo e consente di visualizzare le mappe e analizzare il flusso, le varianti e i colli di bottiglia. Dove reperirli Ricavato da diverse fonti, tra cui i codici di transazione (SY-TCODE), gli stati dei documenti di modifica (tabelle CDHDR/CDPOS) o i registri dei flussi di lavoro aziendali, ad esempio SWW_WI2OBJ. Esempi Fattura generataFattura registrata in contabilitàPagamento del cliente ricevutoFattura annullata | |||
| Ora dell’evento EventTime | Timestamp preciso che indica quando si è verificata un’attività o un evento. | ||
| Descrizione L’ora dell’evento fornisce la data e l’ora di ciascuna attività e costituisce la base cronologica del processo. Questo timestamp è fondamentale per calcolare durate, tempi di ciclo e tempi di attesa tra le diverse fasi del processo di fatturazione. Nell’analisi, l’ora dell’evento serve a ordinare le attività in sequenza, calcolare indicatori chiave come i giorni medi di incasso e il tempo di ciclo di emissione della fattura e individuare i colli di bottiglia legati ai tempi. Consente di osservare il processo nel tempo, mostrando come cambiano le prestazioni e quanto dura ogni fase del ciclo di fatturazione. Perché è importante Fornisce la sequenza cronologica degli eventi, indispensabile per calcolare tutte le metriche temporali, come i tempi di ciclo e le durate. Dove reperirli Estratto da diversi campi di data e ora, a seconda dell’attività, ad esempio data e ora di creazione (VBRK-ERDAT, VBRK-ERZET), timestamp delle modifiche (CDHDR-UDATE, CDHDR-UTIME) o data di registrazione (BKPF-BUDAT). Esempi 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Data di scadenza del pagamento PaymentDueDate | Data entro cui il cliente dovrebbe pagare la fattura. | ||
| Descrizione La data di scadenza del pagamento viene calcolata in base alla data della fattura e alle condizioni di pagamento concordate. Indica il termine entro cui ricevere il pagamento prima che la fattura risulti scaduta. Questo attributo è essenziale per monitorare l’efficacia del recupero crediti e prevedere il flusso di cassa. Viene utilizzato direttamente per calcolare il KPI del tasso di puntualità dei pagamenti e suddividere le fatture nei report sull’anzianità. Analizzare gli scostamenti tra la data di scadenza e quella del pagamento effettivo aiuta a valutare l’efficacia delle diverse condizioni di pagamento. Perché è importante Definisce il termine entro cui il cliente deve pagare ed è quindi fondamentale per calcolare la puntualità dei pagamenti e gestire i crediti verso i clienti. Dove reperirli Questa data non è memorizzata direttamente, ma viene calcolata in base alla data della fattura (VBRK-FKDAT) e al codice delle condizioni di pagamento (VBRK-ZTERM), utilizzando le funzioni standard di SAP per il calcolo delle date. Esempi 2023-04-192023-05-012023-06-17 | |||
| Data fattura InvoiceDate | Data ufficiale di emissione della fattura al cliente. | ||
| Descrizione La data della fattura, denominata in SAP data di fatturazione, è il punto di partenza di molti calcoli finanziari. Da questa data si determinano le condizioni di pagamento, le scadenze e l’anzianità del credito. È un attributo fondamentale a livello di caso per l’analisi finanziaria. Costituisce il riferimento per calcolare il KPI dei giorni medi di incasso (DSO) e creare report sull’anzianità delle fatture aperte, strumenti essenziali per gestire il flusso di cassa e il recupero crediti. Perché è importante È la data di riferimento principale per i calcoli finanziari e il punto di partenza per il DSO, le scadenze dei pagamenti e l’analisi dell’anzianità delle fatture. Dove reperirli Tabella SAP: VBRK, campo: FKDAT Esempi 2023-03-202023-04-012023-05-18 | |||
| Importo della fattura InvoiceAmount | Valore netto totale della fattura. | ||
| Descrizione Questo attributo rappresenta il valore monetario totale dei beni o servizi fatturati, al netto delle imposte. È un dato finanziario fondamentale per ogni caso relativo a una fattura. L’importo della fattura viene utilizzato in numerose analisi. Consente di segmentare il processo in base al valore, ad esempio per verificare se le fatture di importo elevato vengono elaborate diversamente o subiscono più ritardi. È inoltre alla base dei report finanziari e del calcolo del valore totale dei crediti ancora da incassare. Perché è importante Quantifica il valore finanziario di ogni fattura e consente analisi basate sugli importi, di stabilire le priorità nel recupero crediti e di valutare l’impatto finanziario. Dove reperirli Tabella SAP: VBRK, campo: NETWR Esempi 1500.0025000.50125.75 | |||
| Nome cliente CustomerName | Nome del cliente a cui è stata emessa la fattura. | ||
| Descrizione Questo attributo identifica la ragione sociale del cliente a cui viene emessa la fattura. Il dato proviene dai dati anagrafici centrali dei clienti in SAP. Analizzare il processo per cliente consente di individuare schemi ricorrenti relativi a specifici account. Ad esempio, può rivelare quali clienti pagano regolarmente in ritardo, quali presentano più contestazioni o per quali la fatturazione è meno efficiente. Queste informazioni permettono di gestire in modo mirato le relazioni con i clienti e di definire strategie di recupero crediti adeguate. Perché è importante Consente un’analisi incentrata sul cliente, aiutando a individuare le abitudini di pagamento, la frequenza delle contestazioni e le inefficienze del processo per account specifici. Dove reperirli Ricavato dalla tabella dei dati anagrafici dei clienti KNA1 (campo: NAME1), collegata tramite l’ID del pagante nella testata della fattura (VBRK-KUNRG). Esempi Centrale elettrica di SpringfieldMinimarket Kwik-E-MartCyberdyne Systems | |||
| Nome utente UserName | ID dell’utente che ha eseguito l’attività. | ||
| Descrizione Questo attributo registra l’ID utente SAP responsabile di un evento specifico, ad esempio la creazione di una fattura, la registrazione di un documento o la compensazione di un pagamento. Collega le fasi del processo alle persone o ai team che le svolgono. L’analisi per nome utente aiuta a individuare le persone con i risultati migliori, le esigenze di formazione o gli squilibri nella distribuzione del carico di lavoro. È inoltre fondamentale per l’analisi della conformità, perché mostra chi ha svolto le attività critiche, e per capire come utenti diversi eseguono lo stesso processo. Perché è importante Collega le attività del processo a utenti specifici e consente di analizzare il carico di lavoro, le prestazioni e la conformità a livello individuale o di team. Dove reperirli Per gli eventi di creazione, il dato si trova in VBRK-ERNAM. Per le modifiche successive, è disponibile nelle tabelle dello storico delle modifiche, come CDHDR-USERNAME, o nei registri dei flussi di lavoro. Esempi CBURNSHSIMPSONLLEONARD | |||
| Ora di fine EndTime | Data e ora esatte in cui un’attività o un evento è stato completato. | ||
| Descrizione L’ora di fine indica il completamento di un’attività. Nel Process Mining viene spesso dedotta dall’ora di inizio dell’attività successiva nel caso; può anche essere acquisita direttamente se il sistema registra sia gli eventi di inizio sia quelli di fine. Questo attributo è essenziale per calcolare il tempo di elaborazione delle singole attività. Sottraendo l’ora di inizio dall’ora di fine si misura la durata di ogni passaggio, un dato fondamentale per l’analisi dei colli di bottiglia, ad esempio per individuare i ritardi nella fase di approvazione delle fatture. Perché è importante Consente di calcolare la durata esatta, ovvero il tempo di elaborazione, di ogni attività, un dato fondamentale per l’analisi dei colli di bottiglia. Dove reperirli È un attributo derivato per il Process Mining. In genere si calcola utilizzando l’ora di inizio dell’evento successivo nella sequenza del caso. In alcuni scenari, tabelle specifiche possono registrare gli orari di completamento. Esempi 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Regione Region | Area geografica del cliente. | ||
| Descrizione L’attributo Regione indica l’area geografica, ad esempio uno stato o una provincia, associata all’indirizzo del cliente. In genere, il dato fa parte dell’anagrafica del cliente. Questo attributo è fondamentale per la Dashboard delle prestazioni di fatturazione per regione. Consente di confrontare tra diverse regioni metriche chiave come i tempi di ciclo, i tassi di errore e il DSO. Il confronto può mettere in luce differenze regionali nell’esecuzione dei processi, nella conformità o nell’efficienza e favorire miglioramenti mirati e l’adozione di prassi efficaci. Perché è importante Consente di confrontare le prestazioni della fatturazione tra diverse aree geografiche, individuare le disparità regionali e uniformare i processi. Dove reperirli Ricavato dalla tabella dei dati anagrafici dei clienti KNA1 (campo: REGIO), collegata tramite l’ID del pagante nella testata della fattura (VBRK-KUNRG). Esempi CANYTXBA | |||
| Codice società CompanyCode | Unità organizzativa per la quale viene registrata la transazione finanziaria. | ||
| Descrizione Il codice società è un’entità organizzativa fondamentale in SAP Financials e rappresenta una società giuridicamente indipendente per la quale vengono redatti i bilanci. A ogni documento di fatturazione viene assegnato un codice società specifico. Nelle organizzazioni composte da più società, l’analisi per codice società è essenziale per confrontare le prestazioni dei processi, gli indicatori finanziari come il DSO e la conformità delle diverse entità giuridiche. Offre un filtro organizzativo di alto livello per tutte le Dashboard dei processi. Perché è importante Consente di suddividere l’analisi dei processi per entità giuridica, confrontare le prestazioni e consolidare i dati finanziari dell’organizzazione. Dove reperirli Tabella SAP: VBRK, campo: BUKRS Esempi 10002000US01 | |||
| Condizioni di pagamento PaymentTerms | Il codice che definisce le condizioni di pagamento, ad esempio il termine concesso per effettuare il pagamento. | ||
| Descrizione Le condizioni di pagamento sono termini prestabiliti concordati con il cliente, che indicano entro quando deve essere saldata una fattura. Alcuni esempi sono «30 giorni» (pagamento entro 30 giorni) oppure «2/10, 30 giorni» (sconto del 2% se il pagamento avviene entro 10 giorni, altrimenti entro 30 giorni). L’analisi per condizioni di pagamento consente di valutarne l’efficacia. Confrontando le diverse condizioni con i tempi effettivi di incasso, l’azienda può individuare quelle che favoriscono maggiormente i pagamenti puntuali e ottimizzarle per migliorare il flusso di cassa. Perché è importante Definisce le scadenze di pagamento concordate e consente di analizzare quali condizioni sono più efficaci nel favorire i pagamenti puntuali dei clienti. Dove reperirli Tabella SAP: VBRK, campo: ZTERM Esempi Z030Z060ZB60 | |||
| Motivo della contestazione CustomerDisputeReason | Motivo indicato dal cliente per contestare una fattura. | ||
| Descrizione Quando un cliente contesta una fattura, di norma viene registrato il motivo della contestazione, ad esempio un errore di prezzo, una quantità errata o merce danneggiata. Queste informazioni possono essere archiviate nel modulo SAP Dispute Management o in note testuali. L’analisi dei motivi di contestazione è fondamentale per il KPI del tasso di errori di fatturazione e per la relativa analisi degli errori. Aiuta a individuare le cause profonde delle inesattezze di fatturazione, così che l’azienda possa intervenire sui problemi sistemici nei processi a monte, migliorare la qualità delle fatture e aumentare la soddisfazione dei clienti. Perché è importante Spiega perché le fatture vengono contestate e offre indicazioni dirette sulle cause profonde degli errori di fatturazione e dell’insoddisfazione dei clienti. Dove reperirli Se si utilizza SAP Dispute Management, queste informazioni si trovano in tabelle come UDM_DISPUTE. In caso contrario, possono essere ricavate dai codici motivo dei documenti correlati o dai campi di testo. Esempi Prezzo erratoQuantità non corrispondenteMerce ricevuta danneggiata | |||
| Motivo della nota di credito CreditMemoReason | Codice motivo che indica perché è stata emessa una nota di credito. | ||
| Descrizione Quando una fattura contiene errori e deve essere stornata tramite accredito, al documento di nota di credito viene in genere assegnato un motivo. In questo modo è possibile classificare in modo strutturato le cause degli errori di fatturazione. Questo attributo contribuisce direttamente al KPI del tasso di errori di fatturazione. Aggregando e analizzando i motivi delle note di credito, l’azienda può individuare gli errori più frequenti, come quelli di prezzo o i resi dei prodotti. I risultati consentono di migliorare i processi, riducendo la necessità di rettifiche contabili e rilavorazioni. Perché è importante Classifica i motivi delle note di credito e aiuta a individuare le cause più frequenti degli errori di fatturazione, orientando gli interventi per migliorare la qualità. Dove reperirli Tabella SAP: VBRK, campo: AUGRU (motivo dell’ordine). Questo campo viene utilizzato nelle richieste di note di credito o di debito che vengono successivamente fatturate. Esempi 001 - Differenza di prezzo002 - Qualità scadente005 - Reso del cliente | |||
| Numero dell’ordine di vendita SalesOrderNumber | Identificativo dell’ordine di vendita originale da cui ha avuto origine la fattura. | ||
| Descrizione Il numero dell’ordine di vendita collega il documento di fatturazione alle attività di vendita precedenti. Da un singolo ordine possono derivare una o più fatture; questo collegamento consente di ricostruire l’intero flusso documentale. Questo attributo è essenziale per un’analisi end-to-end completa del processo Order-to-Cash. Consente di estendere l’analisi alle fasi precedenti, collegando i problemi di fatturazione alle possibili cause profonde nella creazione o nell’evasione dell’ordine di vendita. Ad esempio, permette di calcolare il tempo complessivo di generazione della fattura a partire dall’evasione dell’ordine. Perché è importante Collega la fattura all’ordine di vendita originale e consente di analizzare l’intero processo Order-to-Cash, non soltanto la fatturazione. Dove reperirli Tabella SAP: VBRP (dati delle posizioni del documento di fatturazione), campo: AUBEL Esempi 100001231000045610000789 | |||
| Pagamento puntuale IsPaidOnTime | Indicatore booleano che specifica se la fattura è stata pagata entro la data di scadenza. | ||
| Descrizione È un attributo calcolato che confronta la data effettiva del pagamento con la data di scadenza prevista. Il risultato è «true» se il pagamento è avvenuto puntualmente e «false» se è stato effettuato in ritardo. Questo indicatore semplifica il calcolo e la visualizzazione del KPI del tasso di pagamenti puntuali. Consente di filtrare e suddividere facilmente i dati per analizzare le caratteristiche delle fatture pagate in ritardo rispetto a quelle saldate puntualmente. In questo modo è possibile individuare schemi ricorrenti legati a determinati clienti, aree geografiche o condizioni di pagamento. Perché è importante Semplifica la misurazione delle prestazioni indicando chiaramente per ogni fattura se il pagamento è stato puntuale o in ritardo e contribuisce direttamente al KPI del tasso di pagamenti puntuali. Dove reperirli È un campo calcolato. La logica confronta la data e l’ora dell’attività «Pagamento ricevuto dal cliente» con il valore dell’attributo «PaymentDueDate». Esempi truefalse | |||
| Sistema di origine SourceSystem | Identifica il sistema di origine specifico da cui sono stati estratti i dati. | ||
| Descrizione Questo attributo specifica l’origine dei dati ed è particolarmente utile negli ambienti con più istanze SAP o altri sistemi integrati. In genere include l’ID del sistema e il numero del mandante. Nell’analisi, aiuta a distinguere i processi e le prestazioni tra sistemi o entità organizzative diverse. Garantisce la tracciabilità dei dati e fornisce il contesto necessario, soprattutto quando si combinano dati provenienti da più fonti per ottenere una visione complessiva del processo. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, garantendo chiarezza negli ambienti con più sistemi e supportando la governance dei dati. Dove reperirli In genere è un valore statico definito durante l’estrazione dei dati, spesso composto dall’ID del sistema (SY-SYSID) e dal mandante (SY-MANDT). Esempi S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Stato del pagamento PaymentStatus | Stato attuale del pagamento della fattura, ad esempio aperto, pagato o scaduto. | ||
| Descrizione Lo stato del pagamento indica a colpo d’occhio a che punto è una fattura nel processo di recupero crediti. In SAP non corrisponde a un singolo campo: si ricava verificando lo stato di compensazione del documento contabile associato. Questo attributo è essenziale per la Dashboard delle fatture insolute per anzianità. Consente di suddividere tutte le fatture aperte in base allo stato e all’anzianità, aiutando il team addetto al recupero crediti a stabilire le priorità. Anche il monitoraggio dei passaggi da uno stato all’altro permette di tenere sotto controllo il processo di recupero crediti. Perché è importante Mostra chiaramente lo stato di recupero crediti di ogni fattura, un’informazione fondamentale per gestire i crediti e definire le priorità delle attività di riscossione. Dove reperirli Si ricava verificando lo stato di compensazione del documento contabile (VBRK-BELNR) in tabelle finanziarie come BSID (partite aperte) e BSAD (partite compensate). Esempi ApertoPagatoScadutoPagato parzialmente | |||
| Tipo di documento di fatturazione BillingDocumentType | Codice che classifica il documento di fatturazione, ad esempio come fattura, nota di credito o annullamento. | ||
| Descrizione Il tipo di documento di fatturazione è un campo chiave che classifica le transazioni nel processo di fatturazione. Determina le modalità di elaborazione del documento, compresi l’intervallo di numerazione e le regole di registrazione contabile. Questo attributo consente di filtrare il processo e analizzare specifici tipi di transazione. Ad esempio, è possibile creare una vista del processo dedicata alle note di credito per comprenderne i motivi e il flusso delle rettifiche finanziarie, oppure analizzare separatamente le fatture standard e gli annullamenti per ottenere un quadro più chiaro del processo di fatturazione principale. Perché è importante Classifica le transazioni e consente di concentrarsi su flussi documentali specifici, come fatture standard, note di credito o annullamenti. Dove reperirli Tabella SAP: VBRK, campo: FKART Esempi F2G2S1L2 | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Timestamp che indica quando i dati di questo evento sono stati estratti o aggiornati l’ultima volta. | ||
| Descrizione Questo attributo registra la data e l’ora dell’ultima estrazione dei dati dal sistema di origine. È un campo di metadati fondamentale per capire quanto siano aggiornati i dati analizzati. Queste informazioni servono a verificare l’attualità dell’analisi e a gestire la pianificazione degli aggiornamenti dei dati. Consentono alle parti interessate di sapere quanto sono recenti i dati quando prendono decisioni sulla base delle Dashboard e degli approfondimenti di Process Mining. Perché è importante Indica quanto sono aggiornati i dati, un aspetto essenziale per potersi fidare dell’analisi e valutarne la rilevanza rispetto alla situazione operativa attuale. Dove reperirli Questo timestamp viene generato e aggiunto a ogni record durante il processo di estrazione e caricamento dei dati (ETL). Esempi 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Valuta Currency | Codice della valuta in cui è espresso l’importo della fattura. | ||
| Descrizione Questo attributo specifica la valuta in cui sono espressi gli importi delle fatture, ad esempio USD, EUR o JPY. Fornisce il contesto necessario per interpretare tutti i valori monetari. In un’organizzazione globale, la valuta è essenziale per garantire analisi e report finanziari corretti. Consente di aggregare correttamente i dati finanziari convertendo tutti gli importi in un’unica valuta di rendicontazione e di confrontare le prestazioni della fatturazione tra aree geografiche che utilizzano valute locali diverse. Perché è importante Fornisce il contesto necessario per interpretare tutti i valori monetari e garantire analisi e report finanziari accurati, soprattutto nelle organizzazioni multinazionali. Dove reperirli Tabella SAP: VBRK, campo: WAERK Esempi USDEURGBP | |||
Attività del processo Order-to-Cash: fatturazione
| Attività | Descrizione | ||
|---|---|---|---|
| Fattura chiusa | Questa attività indica lo stato finale di una fattura pagata correttamente. Dal punto di vista funzionale equivale a «Incasso registrato e riconciliato» e segnala che il processo relativo alla fattura è concluso. | ||
| Perché è importante È l’evento finale del percorso ottimale del processo. Misurare il tempo di ciclo totale fino a questo punto offre una visione completa dell’intero ciclo di fatturazione. Dove reperirli Lo stato viene dedotto dalla partita cliente nel documento contabile. Una partita è chiusa, o «compensata», quando sono valorizzati i campi della data di compensazione (BSEG-AUGDT) e del documento di compensazione (BSEG-AUGBL). Acquisizione Lo stato viene dedotto dalla presenza della data di compensazione (AUGDT) nella tabella BSEG/ACDOCA per la partita della fattura. Tipo di evento inferred | |||
| Fattura generata | Questa attività indica la creazione del documento di fatturazione nel sistema. Si tratta di un evento esplicito, registrato quando un utente esegue una transazione come VF01 oppure quando un processo in background crea la fattura, generando una nuova voce nella tabella di testata dei documenti di fatturazione. | ||
| Perché è importante È l’evento di inizio principale del processo di fatturazione. Analizzare il tempo che intercorre tra l’evasione dell’ordine e questa attività è fondamentale per misurare il tempo di ciclo di emissione della fattura e individuare i ritardi iniziali del processo. Dove reperirli Registrato nella tabella VBRK di SAP S/4HANA (documento di fatturazione: dati di testata) al momento della creazione. La data di creazione (VBRK-ERDAT) e l’ora (VBRK-ERZET) costituiscono il timestamp. Acquisizione L’evento viene acquisito dal timestamp di creazione del record del documento di fatturazione nella tabella VBRK. Tipo di evento explicit | |||
| Fattura registrata in contabilità | Indica che il documento di fatturazione è stato registrato correttamente nel modulo di contabilità finanziaria. È una tappa fondamentale: la fattura diventa un credito ufficiale verso il cliente e genera registrazioni nel libro mastro. | ||
| Perché è importante Questa attività conferma che la fattura è un documento finanziario ufficiale. Il tempo che intercorre tra la generazione e la registrazione è un indicatore chiave delle prestazioni, che mette in luce l’efficienza dei processi interni. Dove reperirli L’evento viene acquisito quando viene creato il documento contabile corrispondente. Il documento di fatturazione (VBRK-VBELN) è collegato al documento contabile (BKPF-BELNR) tramite VBRK-BELNR; la data di registrazione è BKPF-BUDAT. Acquisizione Acquisito dalla data di registrazione (BUDAT) del documento contabile nella tabella BKPF collegato al documento di fatturazione. Tipo di evento explicit | |||
| Incasso registrato e riconciliato | Indica il momento in cui il pagamento ricevuto dal cliente viene associato alla partita aperta della fattura e utilizzato per chiuderla nel sottoconto clienti. Da un punto di vista finanziario, questa attività completa la transazione. | ||
| Perché è importante Misura l’efficienza del processo di registrazione degli incassi. I ritardi in questa fase possono fornire un quadro inesatto della situazione dei conti dei clienti e generare lavoro superfluo per i team addetti al recupero crediti. Dove reperirli L’evento viene acquisito dalla data di compensazione (BSEG-AUGDT) nella partita del documento contabile della fattura originale. Questo campo viene valorizzato quando un documento di compensazione chiude la partita. Acquisizione Acquisito dal campo della data di compensazione (AUGDT) nella tabella BSEG/ACDOCA per la partita della fattura. Tipo di evento explicit | |||
| Pagamento del cliente ricevuto | Questa attività indica la registrazione nel sistema finanziario di un pagamento ricevuto da un cliente. In questa fase il pagamento potrebbe non essere ancora associato a una fattura specifica, ma l’incasso è stato registrato. | ||
| Perché è importante È una tappa fondamentale per calcolare i giorni medi di incasso (DSO). Indica che il pagamento è stato ricevuto, anche se la riconciliazione è ancora in sospeso. Dove reperirli Acquisito dalla data di registrazione (BKPF-BUDAT) del documento di pagamento del cliente, in genere di tipo «DZ» nella tabella BKPF. Acquisizione L’evento si basa sulla creazione del documento di pagamento in BKPF/BSEG. Tipo di evento explicit | |||
| Contestazione del cliente aperta | Questa attività si verifica quando un cliente contesta una fattura e la contestazione viene registrata formalmente nel sistema. È necessario utilizzare il modulo SAP Dispute Management. | ||
| Perché è importante Mette in evidenza problemi di accuratezza della fatturazione, qualità dei prodotti o erogazione dei servizi che causano ritardi nei pagamenti. Analizzare i motivi delle contestazioni aiuta a intervenire sulle cause profonde e a migliorare la soddisfazione dei clienti. Dove reperirli Registrato alla creazione di un caso di contestazione nelle tabelle di Dispute Management, ad esempio UDM_CASE, collegato alla partita del documento contabile. Acquisizione Acquisito dal timestamp di creazione del record del caso di contestazione collegato alla fattura. Tipo di evento explicit | |||
| Fattura annullata | Si verifica quando una fattura già creata viene annullata, di norma con la creazione del relativo documento di storno. In questo modo si annullano di fatto la fattura originale e i suoi effetti contabili. | ||
| Perché è importante Indica rilavorazioni, correzioni o errori di fatturazione. Un numero elevato di annullamenti segnala problemi significativi nelle fasi precedenti, come l’inserimento degli ordini di vendita o la configurazione della fatturazione. Dove reperirli Acquisito alla creazione di un documento di fatturazione di annullamento, ad esempio di tipo «S1». Il nuovo documento in VBRK fa riferimento al numero della fattura originale nel campo VBRK-SFAKN. Acquisizione L’evento viene acquisito dalla data di creazione in VBRK del documento di annullamento che fa riferimento alla fattura originale. Tipo di evento explicit | |||
| Fattura inviata al cliente | Questa attività indica l’invio della fattura al cliente, ad esempio tramite stampa, e-mail o EDI. Il metodo di acquisizione dipende dalla configurazione della gestione degli output in SAP. | ||
| Perché è importante Dal punto di vista del cliente, segna l’inizio ufficiale del periodo di pagamento. I ritardi nell’invio della fattura incidono direttamente sui giorni medi di incasso (DSO) e sul flusso di cassa. Dove reperirli L’evento può essere registrato esplicitamente nelle tabelle di controllo degli output, ad esempio NAST per i metodi meno recenti o il relativo equivalente in S/4HANA. Se non viene registrato esplicitamente, spesso si presume che avvenga nello stesso momento della «Fattura registrata in contabilità». Acquisizione Controllare nei registri di elaborazione delle tabelle di gestione degli output la presenza di un timestamp associato al tipo di output della fattura. Tipo di evento explicit | |||
| Nota di credito creata | Questa attività indica la creazione di una nota di credito, emessa per correggere un importo fatturato in eccesso o riconoscere un credito per merci restituite. Spesso è collegata a una fattura originale. | ||
| Perché è importante Mette in evidenza i problemi che comportano rettifiche finanziarie dopo la fatturazione. Analizzare le note di credito può far emergere errori di prezzo, problemi relativi ai prodotti o altre cause profonde delle perdite di ricavi. Dove reperirli Viene creato esplicitamente un nuovo documento di fatturazione in VBRK, con un tipo specifico per le note di credito, ad esempio «G2». Spesso fa riferimento all’ordine di vendita o alla fattura originale. Acquisizione Acquisito alla creazione in VBRK di un documento di fatturazione con un tipo previsto per le note di credito. Tipo di evento explicit | |||
| Registrazione della fattura bloccata | L’evento si verifica quando una fattura viene creata, ma il sistema ne blocca automaticamente la registrazione in contabilità finanziaria per vari motivi, ad esempio controlli del credito o incongruenze nei dati. Lo stato viene dedotto dal campo relativo allo stato di registrazione del documento di fatturazione. | ||
| Perché è importante Individua i colli di bottiglia in cui le fatture vengono create ma non rilasciate subito alla contabilità, ritardando l’intero ciclo di incasso. È un indicatore importante di problemi nella qualità dei dati o nella gestione del credito. Dove reperirli Lo stato viene dedotto dal campo relativo allo stato di registrazione nella tabella di testata del documento di fatturazione (VBRK-RFBSK). Un valore come «A» (documento di fatturazione bloccato per l’inoltro a FI) indica un blocco. Acquisizione Lo stato viene dedotto controllando il valore del campo relativo alla registrazione (VBRK-RFBSK) subito dopo la generazione della fattura. Tipo di evento inferred | |||
| Rilavorazione della fatturazione individuata | Evento calcolato che individua un ciclo di rilavorazione: una fattura viene annullata e ne viene generata una nuova per lo stesso ordine di vendita. Non corrisponde a una singola transazione, ma a una sequenza di eventi. | ||
| Perché è importante Contribuisce direttamente al KPI del tasso di rilavorazione della fatturazione, quantificando gli interventi correttivi. Aiuta a individuare le inefficienze e a misurare il costo della scarsa qualità nel processo di fatturazione. Dove reperirli La sequenza viene calcolata individuando un evento «Fattura annullata» seguito da un nuovo evento «Fattura generata», entrambi riconducibili allo stesso documento di origine, ad esempio un numero d’ordine di vendita. Acquisizione Ricavato individuando la sequenza «Fattura annullata» e «Fattura generata» per lo stesso riferimento all’ordine di vendita. Tipo di evento calculated | |||
| Scadenza del pagamento raggiunta | Evento calcolato che rappresenta la data entro cui, secondo le condizioni di pagamento concordate, la fattura deve essere saldata. Non è un evento transazionale, ma viene ricavato dai dati della fattura. | ||
| Perché è importante Fornisce un riferimento essenziale per misurare la puntualità dei pagamenti e analizzare il comportamento dei clienti. Aiuta a distinguere i pagamenti puntuali da quelli in ritardo. Dove reperirli Calcolato in base alla data di riferimento per il pagamento (BSEG-ZFBDT) e alle condizioni di pagamento memorizzate nella partita cliente del documento contabile. Acquisizione Ricavato aggiungendo i giorni previsti dalle condizioni di pagamento alla data di riferimento indicata nella partita del documento contabile (BSEG). Tipo di evento calculated | |||
| Sollecito di pagamento inviato | Indica l’invio al cliente di un sollecito di pagamento per una fattura scaduta. È un evento esplicito generato dalla procedura automatizzata di sollecito. | ||
| Perché è importante Consente di analizzare l’efficacia del processo di sollecito. Aiuta a capire se i solleciti accelerano i pagamenti e quali livelli di sollecito hanno maggiore impatto. Dove reperirli Registrato nelle tabelle dello storico dei solleciti (MAHNV, MHND) quando viene eseguita la procedura di sollecito (transazione F150) per la partita aperta della fattura. Acquisizione Acquisito dalla data di esecuzione del sollecito registrata nelle tabelle dello storico dei solleciti. Tipo di evento explicit | |||
Guide all’estrazione
Passaggi
- Prerequisiti: Verifichi di disporre di un account utente SAP S/4HANA con le autorizzazioni necessarie per interrogare le viste Core Data Services (CDS). In particolare, occorre l’accesso in lettura a viste come I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase e I_DunningHistory.
- Accesso allo strumento di estrazione dei dati: Acceda al sistema SAP S/4HANA. Per eseguire query SQL sulle viste CDS può utilizzare diversi strumenti, ad esempio SAP HANA Studio, DBeaver connesso tramite il client SAP HANA oppure il plug-in SAP Analysis for Microsoft Excel. In questa guida si presuppone l’uso di un client SQL standard.
- Individuazione dei parametri di sistema: Prima di eseguire la query, individui i codici società specifici e l’intervallo di date pertinente per l’analisi. Per contenere i tempi di esecuzione, è consigliabile iniziare con un ambito limitato, ad esempio gli ultimi 3-6 mesi di dati.
- Preparazione della query SQL: Copi la query SQL completa riportata nella sezione 'query' di questo documento nel client SQL scelto.
- Personalizzazione dei segnaposto: Modifichi i valori segnaposto nella query. Sostituisca
'YYYY-MM-DD'con le date di inizio e fine desiderate e'XXXX'con i codici società di destinazione. Potrebbe inoltre essere necessario modificare il segnaposto relativo ai tipi di documento delle note di credito, ad esempio'G2', in base alla configurazione del sistema. - Esecuzione della query: Esegua la query SQL modificata sul database SAP S/4HANA. I tempi di esecuzione variano in base al volume di dati nell’intervallo selezionato.
- Revisione dei risultati: Al termine della query, riveda i risultati. Il set restituito dovrebbe essere una tabella piatta, in cui ogni riga rappresenta una singola attività del processo di fatturazione. Questo è il Suo event log.
- Trasformazione dei dati (se necessaria): La query è progettata per produrre un event log in un formato pulito. Verifichi comunque che il formato dei timestamp sia compatibile con lo strumento di Process Mining. La query usa
ABAP_SYSTEM_UTCL_TO_TIMESTAMPper convertire i valori in timestamp UTC standard, un formato ampiamente compatibile. - Esportazione dell’Event Log: Esporti l’intero set di risultati dal client SQL in un file CSV. Verifichi che il file sia codificato in UTF-8 per evitare problemi con i caratteri.
- Caricamento in ProcessMind: Carichi il file CSV generato sulla piattaforma ProcessMind e associ le colonne del file, ad esempio InvoiceNumber, ActivityName ed EventTime, ai campi corrispondenti nello strumento.
Configurazione
- Intervallo di date: Imposti le date di inizio e fine nella clausola
WHEREdella Common Table Expression (CTE) iniziale. Per la prima analisi si consiglia un intervallo di 3-6 mesi, così da bilanciare il volume dei dati e le prestazioni. Il filtro si applica aBillingDocumentDate. - Codice società: Applichi un filtro su uno o più valori
CompanyCodeper limitare l’estrazione alle entità giuridiche pertinenti. È un filtro essenziale per controllare l’ambito dei dati. - Tipi di documento: La query include una logica per individuare le note di credito in base a
BillingDocumentType. Configuri il segnaposto, ad esempio('G2', 'CR'), con i tipi di documento specifici utilizzati dall’organizzazione per le note di credito. - Prerequisiti: È obbligatorio poter accedere alle viste CDS sottostanti. A tal fine, il team di sicurezza SAP deve assegnare ruoli e autorizzazioni specifici. Inoltre, per attività come 'Customer Dispute Opened' o 'Payment Reminder Issued', nel sistema devono essere effettivamente utilizzati i rispettivi moduli SAP Dispute Management e SAP Financials Dunning.
- Prestazioni: La query utilizza più join e unioni. Per set di dati molto ampi, ad esempio relativi a diversi anni, valuti di eseguirla nelle fasce orarie di minore attività oppure di applicare filtri più restrittivi per limitare l’estrazione iniziale.
Query di esempio sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Passaggi
- Verifichi che sia disponibile l’accesso diretto in lettura allo schema SAP HANA che contiene le tabelle di fatturazione e quelle finanziarie correlate. Richieda al responsabile del sistema il nome dello schema, i dettagli di connessione, l’intervallo di date autorizzato, l’ambito dei codici società, i tipi di documento di fatturazione e gli eventuali filtri per cliente o area geografica. Sostituisca nella query solo i segnaposto relativi alla connessione e ai filtri.
- Verifichi le origini dati SAP S/4HANA pertinenti e le relative associazioni dei campi nel sistema di destinazione. La query utilizza VBRK e VBRP per i dati di fatturazione e richiede origini configurate per contabilità, gestione dell’output, gestione delle contestazioni, solleciti, pagamenti in entrata, compensazioni e relazioni tra documenti. Sostituisca i segnaposto tra parentesi quadre relativi alle origini e ai campi solo dopo averli verificati nel dizionario dei dati di sistema.
- Configuri il periodo di estrazione usando un timestamp iniziale incluso e uno finale escluso. Per la prima esecuzione si consiglia un periodo di tre-sei mesi. Limiti l’estrazione per codice società e, se opportuno, per tipo di fatturazione, così da controllare il volume ed evitare di mescolare processi di fatturazione non correlati.
- Esegua la query con un utente del database HANA con autorizzazioni di sola lettura. La query crea una riga di evento per ogni attività estratta esplicitamente. Non si affida a ProcessMind per dedurre gli eventi. Le attività calcolate, tra cui Payment Due Date Reached e Billing Rework Identified, sono generate dalla logica SQL e restituite come righe.
- Convalidi lo schema restituito. L’event log deve contenere InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region ed EndTime. Verifichi che InvoiceNumber, ActivityName ed EventTime siano valorizzati in ogni riga.
- Convalidi la semantica degli eventi e le relazioni. Confronti le righe Invoice Generated con i dati di creazione delle intestazioni di fatturazione, le righe Invoice Posted To Accounting con lo stato di registrazione contabile, le righe Invoice Sent To Customer con i record di output, le righe di pagamento con i documenti contabili e le righe di compensazione con le partite fattura compensate. Riveda tutte le sezioni che dipendono da segnaposto prima dell’uso in produzione.
- Normalizzi il risultato per ProcessMind. Mantenga una riga per evento, utilizzi un tipo di timestamp e un fuso orario coerenti, conservi InvoiceNumber come testo per mantenere gli zeri iniziali e verifichi che i valori ActivityName corrispondano esattamente ai nomi delle attività richiesti. Ordini per InvoiceNumber ed EventTime, aggiungendo un criterio secondario deterministico se più eventi hanno lo stesso timestamp.
- Esporti il risultato in formato CSV UTF-8 o in un altro formato tabellare supportato da ProcessMind. Mappi InvoiceNumber come identificativo del caso, ActivityName come colonna dell’attività ed EventTime come timestamp dell’evento. Includa gli attributi consigliati, se disponibili, quindi carichi il file tramite il processo di importazione ProcessMind configurato ed esegua un controllo finale sul numero di righe e di attività.
Configurazione
- Intervallo di date: Inizi con un periodo da tre a sei mesi. Utilizzi un timestamp iniziale incluso e uno finale escluso per evitare eventi duplicati tra esecuzioni incrementali.
- Identificativo del caso: Utilizzi InvoiceNumber dall’intestazione del documento di fatturazione. Lo conservi come stringa, poiché i numeri dei documenti SAP possono iniziare con zeri.
- Attività richieste: L’estrazione deve restituire righe esplicite per Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created e Billing Rework Identified.
- Filtri: Applichi i filtri per codice società, tipo di documento di fatturazione, organizzazione commerciale, cliente, area geografica e date solo dopo aver verificato i campi corrispondenti e l’ambito aziendale nel sistema di destinazione. Non presuma che tutti i tipi di documento di fatturazione seguano lo stesso processo contabile o di output.
- Configurazione delle origini: VBRK e VBRP sono le principali origini dei dati di fatturazione. Le origini per contabilità, output, contestazioni, solleciti, pagamenti, compensazioni e flusso dei documenti devono essere configurate in base alla versione SAP S/4HANA installata e ai moduli abilitati. Sostituisca i riferimenti alle origini tra parentesi quadre con oggetti e campi convalidati.
- Eventi calcolati: Payment Due Date Reached è ricavato dai termini di pagamento e dai dati di scadenza. Billing Rework Identified è ricavato dai modelli di annullamento e successiva generazione della fattura. Si tratta di righe di evento generate da SQL, non di record transazionali nativi.
- Prestazioni: Applichi i filtri per data, codice società, tipo di fatturazione e numero di documento in ogni query sulle origini. Selezioni solo le colonne necessarie, eviti join senza restrizioni con tabelle contabili di grandi dimensioni, elabori il periodo in lotti mensili o settimanali e utilizzi i piani di esecuzione del database per individuare i join più onerosi.
- Estrazione incrementale: Utilizzi un watermark stabile basato sui timestamp di creazione o registrazione dell’origine. Rielabori una breve finestra di sovrapposizione per acquisire i record di output, pagamento, contestazione e compensazione arrivati in ritardo, quindi rimuova i duplicati usando InvoiceNumber, ActivityName ed EventTime insieme alla chiave del documento di origine pertinente.
- Autorizzazioni: L’utente che esegue l’estrazione deve disporre delle autorizzazioni di lettura per gli oggetti e i campi selezionati dello schema HANA. Verifichi che l’accesso diretto al database sia consentito dalle norme di sicurezza dell’organizzazione e che siano rispettati i requisiti per il trattamento dei dati personali e dei clienti.
- Prerequisiti funzionali: I dati di gestione dell’output, integrazione contabile, gestione delle contestazioni, solleciti, pagamenti in entrata e compensazioni sono disponibili solo se le relative funzionalità sono configurate e utilizzate nel sistema. Se mancano moduli o record di origine, le attività non saranno presenti e non verranno dedotte.
- Fuso orario: Uniformi i timestamp al fuso orario richiesto da ProcessMind. Documenti se i timestamp di origine sono archiviati in UTC, nell’ora locale del sistema o in un altro fuso orario configurato.
Query di esempio sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; È pronto per iniziare?
Utilizzi questo template per velocizzare la preparazione dei dati e iniziare a ottimizzare il processo Order to Cash - Fatturazione ed emissione delle fatture. Trasformi oggi stesso i dati SAP S/4H4ANA in informazioni utili per agire.
Ottimizzi la fatturazione Order to Cash per accelerare del 30% il flusso di cassa
Elimini le inefficienze e riduca del 30% il tempo del ciclo di fatturazione, a partire da oggi.
Non è richiesta alcuna carta di credito. Inizi in pochi minuti.