Il Suo Template dei dati per Order to Cash, fatturazione ed emissione delle fatture
Il Suo Template dei dati per Order to Cash, fatturazione ed emissione delle fatture
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l'estrazione da SAP S/4HANA
Attributi di Order to Cash - Fatturazione ed emissione delle fatture
| Nome | Descrizione | ||
|---|---|---|---|
| Numero della fattura InvoiceNumber | L'identificativo univoco di un documento di fatturazione, che funge da identificativo principale del caso nel processo di fatturazione. | ||
| Descrizione Il numero della fattura, noto in SAP come numero del documento di fatturazione, identifica univocamente ogni transazione di fatturazione. Funge da 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 la correlazione dei casi. Tutti gli eventi che condividono lo stesso numero della fattura vengono raggruppati in una singola istanza di processo, consentendo un'analisi completa end-to-end del ciclo di vita di ogni singola fattura. In questo modo è possibile monitorare i tempi di ciclo, identificare 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, rendendo possibile l'analisi end-to-end del processo. Dove reperirlo Tabella SAP: VBRK, campo: VBELN Esempi 900012349000567890009012 | |||
| Nome dell'attività ActivityName | Il nome dell'attività o dell'evento aziendale che si è verificato nel processo di fatturazione, ad esempio 'Fattura generata' o 'Pagamento ricevuto'. | ||
| Descrizione Il nome dell'attività descrive una fase o un traguardo specifico nel ciclo di vita della fatturazione. Queste attività derivano da diversi punti dati in SAP, come codici transazione, variazioni dello stato dei documenti o voci specifiche nei log, e consentono di creare un flusso di processo sequenziale. L'analisi della sequenza e della frequenza di queste attività costituisce il nucleo del Process Mining. Aiuta a visualizzare la mappa del processo, individuare le varianti comuni e rare, identificare i colli di bottiglia tra le fasi e misurare la frequenza di attività senza valore aggiunto, come rilavorazioni o annullamenti. Perché è importante Questo attributo definisce le fasi del processo, consentendo di visualizzare le mappe di processo e analizzare il flusso, le variazioni e i colli di bottiglia. Dove reperirlo Derivato da diverse fonti, tra cui codici transazione (SY-TCODE), stati dei documenti di modifica (tabelle CDHDR/CDPOS) o log dei Workflow aziendali (ad esempio, SWW_WI2OBJ). Esempi Fattura generataFattura registrata in contabilitàPagamento del cliente ricevutoFattura annullata | |||
| Ora dell'evento EventTime | Il timestamp preciso che indica quando si è verificata un'attività o un evento. | ||
| Descrizione L'ora dell'evento fornisce data e ora di ogni attività e costituisce la struttura cronologica portante 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 viene utilizzata per ordinare le attività in sequenza, calcolare indicatori chiave di prestazione come i giorni medi di incasso (DSO) e il tempo di ciclo di generazione della fattura, nonché identificare i colli di bottiglia legati al tempo. Consente una visione dinamica del processo, mostrando come cambiano le prestazioni nel tempo e quanto dura ciascuna fase del ciclo di fatturazione. Perché è importante Fornisce la sequenza cronologica degli eventi, essenziale per calcolare tutte le metriche basate sul tempo, come tempi di ciclo e durate. Dove reperirlo Estratta da diversi campi di data e ora, a seconda dell'attività, come 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 della fattura InvoiceDate | La data ufficiale in cui la fattura è stata emessa al cliente. | ||
| Descrizione La data della fattura, nota in SAP anche come data di fatturazione, costituisce il punto di partenza per numerosi calcoli finanziari. È la data a partire dalla quale vengono determinati i termini di pagamento, le scadenze e l'anzianità del credito. Questa data è un attributo fondamentale a livello di caso per l'analisi finanziaria. Costituisce la base per calcolare il KPI dei giorni medi di incasso (DSO) e creare report sull'anzianità delle fatture aperte, strumenti essenziali per la gestione del flusso di cassa e del recupero crediti. Perché è importante È la data principale per i calcoli finanziari e costituisce il punto di partenza per il DSO, le scadenze dei pagamenti e l'analisi dell'anzianità delle fatture. Dove reperirlo Tabella SAP: VBRK, campo: FKDAT Esempi 2023-03-202023-04-012023-05-18 | |||
| Data di scadenza del pagamento PaymentDueDate | La data entro la quale il cliente dovrebbe pagare la fattura. | ||
| Descrizione La data di scadenza del pagamento viene calcolata in base alla data della fattura e ai termini di pagamento concordati. Rappresenta il termine entro il quale ricevere il pagamento senza che la fattura diventi 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 pagamento puntuale e per segmentare le fatture nei report sull'anzianità. L'analisi degli scostamenti tra la data di scadenza e la data effettiva del pagamento aiuta a valutare l'efficacia dei diversi termini di pagamento. Perché è importante Stabilisce il termine per il pagamento da parte del cliente, risultando quindi fondamentale per calcolare i tassi di pagamento puntuale e gestire i crediti verso clienti. Dove reperirlo Questa data non è memorizzata direttamente, ma viene calcolata in base alla data della fattura (VBRK-FKDAT) e alla chiave dei termini di pagamento (VBRK-ZTERM), utilizzando le funzioni standard SAP per la determinazione delle date. Esempi 2023-04-192023-05-012023-06-17 | |||
| Importo della fattura InvoiceAmount | Il 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 in modo diverso o subiscono più ritardi. Costituisce inoltre la base per la reportistica finanziaria e per calcolare il valore totale dei crediti ancora da incassare. Perché è importante Quantifica il valore finanziario di ogni fattura, consentendo analisi basate sul valore, la definizione delle priorità nel recupero crediti e la valutazione dell'impatto finanziario. Dove reperirlo Tabella SAP: VBRK, campo: NETWR Esempi 1500.0025000.50125.75 | |||
| Nome del cliente CustomerName | Il nome del cliente al quale è stata emessa la fattura. | ||
| Descrizione Questo attributo identifica la denominazione legale del cliente a cui viene fatturato l'importo. Viene ricavato dai dati anagrafici centrali dei clienti in SAP. L'analisi del processo per cliente consente di individuare schemi specifici per determinati account. Può, ad esempio, mostrare quali clienti pagano sistematicamente in ritardo, quali presentano il maggior numero di contestazioni o per quali il processo di fatturazione è più inefficiente. In questo modo è possibile adottare una gestione mirata della relazione con il cliente e strategie di recupero personalizzate. Perché è importante Consente un'analisi incentrata sul cliente, aiutando a identificare comportamenti di pagamento, frequenza delle contestazioni e inefficienze di processo per account specifici. Dove reperirlo Recuperato dalla tabella dei dati anagrafici clienti KNA1 (campo: NAME1), collegata tramite l'ID del pagatore nell'intestazione della fattura (VBRK-KUNRG). Esempi Centrale elettrica di SpringfieldKwik-E-MartCyberdyne Systems | |||
| Nome utente UserName | L'ID utente del dipendente che ha eseguito l'attività. | ||
| Descrizione Questo attributo acquisisce l'ID utente SAP responsabile di un determinato evento, come 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 eseguono. L'analisi per nome utente aiuta a identificare le persone con le migliori prestazioni, le esigenze formative o gli squilibri nella distribuzione del carico di lavoro. È inoltre fondamentale per l'analisi della conformità, poiché mostra chi ha eseguito le attività critiche, e per comprendere le differenze nel modo in cui utenti diversi eseguono lo stesso processo. Perché è importante Collega le attività del processo a utenti specifici, consentendo di analizzare carico di lavoro, prestazioni e conformità a livello individuale o di team. Dove reperirlo Per gli eventi di creazione, si trova in VBRK-ERNAM. Per le modifiche successive, è presente in tabelle dello storico delle modifiche come CDHDR-USERNAME o nei log dei Workflow. Esempi CBURNSHSIMPSONLLEONARD | |||
| Ora di fine EndTime | Il timestamp preciso che indica quando un'attività o un evento è stato completato. | ||
| Descrizione L'ora di fine indica il completamento di un'attività. Nel Process Mining, spesso viene dedotta come ora di inizio dell'attività successiva nel caso oppure può 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 è possibile misurare la durata di ogni fase, un dato fondamentale per l'analisi dei colli di bottiglia, ad esempio per identificare i ritardi nella fase di approvazione della fattura. Perché è importante Consente di calcolare la durata esatta, ovvero il tempo di elaborazione, di ogni attività, elemento fondamentale per l'analisi dei colli di bottiglia. Dove reperirlo È un attributo derivato per il Process Mining. In genere viene calcolato come StartTime dell'evento successivo nella sequenza del caso. In alcuni scenari, tabelle specifiche possono registrare i tempi di completamento. Esempi 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Regione Region | La regione geografica del cliente. | ||
| Descrizione L'attributo Regione indica l'area geografica, ad esempio uno stato o una provincia, associata all'indirizzo del cliente. Questi dati fanno generalmente parte dell'anagrafica cliente. Questo attributo è fondamentale per la Dashboard delle prestazioni regionali della fatturazione. Consente di confrontare indicatori chiave come tempi di ciclo, tassi di errore e DSO tra regioni diverse. Il confronto può evidenziare differenze regionali nell'esecuzione dei processi, nella conformità o nell'efficienza, favorendo miglioramenti mirati e la standardizzazione delle best practice. Perché è importante Consente di confrontare le prestazioni della fatturazione tra diverse aree geografiche, aiutando a individuare disparità regionali e standardizzare i processi. Dove reperirlo Recuperato dalla tabella dei dati anagrafici clienti KNA1 (campo: REGIO), collegata tramite l'ID del pagatore nell'intestazione della fattura (VBRK-KUNRG). Esempi CANYTXBA | |||
| Codice società CompanyCode | L'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. Ogni documento di fatturazione viene assegnato a uno specifico codice società. L'analisi per codice società è essenziale nelle organizzazioni composte da più società, per confrontare le prestazioni dei processi, le metriche finanziarie come il DSO e la conformità tra diverse entità giuridiche. Fornisce un filtro organizzativo di alto livello per tutte le Dashboard di processo. Perché è importante Consente di segmentare l'analisi dei processi per entità giuridica, permettendo il confronto delle prestazioni e il consolidamento finanziario a livello organizzativo. Dove reperirlo Tabella SAP: VBRK, campo: BUKRS Esempi 10002000US01 | |||
| Motivo della contestazione CustomerDisputeReason | Il motivo indicato dal cliente per contestare una fattura. | ||
| Descrizione Quando un cliente contesta una fattura, il motivo della contestazione viene spesso registrato. Può trattarsi di errori di prezzo, quantità errate o merci danneggiate. Queste informazioni possono essere memorizzate nel modulo SAP Dispute Management o come note testuali. L'analisi dei motivi delle contestazioni è fondamentale per il KPI del tasso di errore della fatturazione e per la relativa analisi degli errori. Aiuta a identificare le cause alla radice delle inesattezze di fatturazione, consentendo all'azienda di 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, offrendo una visione diretta delle cause alla radice degli errori di fatturazione e dell'insoddisfazione dei clienti. Dove reperirlo Se viene utilizzato SAP Dispute Management, queste informazioni possono essere reperite in tabelle come UDM_DISPUTE. In caso contrario, possono essere ricavate dai codici motivo dei documenti correlati o dai campi di testo. Esempi Prezzo erratoDiscrepanza nella quantitàMerce danneggiata ricevuta | |||
| Motivo della nota di credito CreditMemoReason | Il codice motivo che indica perché è stata emessa una nota di credito. | ||
| Descrizione Quando una fattura è errata e deve essere accreditata, al documento della nota di credito viene generalmente assegnato un motivo. Questo offre un metodo strutturato per classificare le origini degli errori di fatturazione. Questo attributo supporta direttamente il KPI del tasso di errore della fatturazione. Aggregando e analizzando i motivi delle note di credito, un'azienda può identificare le tipologie di errore più frequenti, come errori di prezzo o resi di prodotti. L'analisi orienta i miglioramenti di processo volti a ridurre la necessità di rettifiche finanziarie e rilavorazioni. Perché è importante Classifica i motivi dell'emissione del credito, aiutando a individuare le fonti più frequenti degli errori di fatturazione e a promuovere miglioramenti della qualità. Dove reperirlo Tabella SAP: VBRK, campo: AUGRU (motivo dell'ordine). Questo campo viene utilizzato nelle richieste di note di credito/debito che vengono successivamente fatturate. Esempi 001 - Differenza di prezzo002 - Qualità insufficiente005 - Reso del cliente | |||
| Numero dell'ordine di vendita SalesOrderNumber | L'identificativo dell'ordine di vendita originale che ha portato alla fattura. | ||
| Descrizione Il numero dell'ordine di vendita collega il documento di fatturazione alle attività di vendita precedenti. Un singolo ordine di vendita può generare una o più fatture e questo collegamento fornisce il flusso documentale completo. Questo attributo è fondamentale per una vera analisi end-to-end Order-to-Cash. Consente di estendere la vista del processo a monte, collegando i problemi di fatturazione alle possibili cause alla radice nelle fasi di creazione o di evasione dell'ordine di vendita. Ad esempio, aiuta a calcolare il tempo di ciclo complessivo di generazione della fattura a partire dal momento in cui l'ordine è stato evaso. Perché è importante Collega la fattura all'ordine di vendita originale, consentendo una visione più ampia ed end-to-end del processo Order-to-Cash, oltre la sola fatturazione. Dove reperirlo Tabella SAP: VBRP (dati delle posizioni del documento di fatturazione), campo: AUBEL Esempi 100001231000045610000789 | |||
| Pagata puntualmente IsPaidOnTime | Un flag booleano che indica se la fattura è stata pagata entro o alla data di scadenza. | ||
| Descrizione È un attributo calcolato che confronta la data effettiva del pagamento con la data di scadenza prevista. Restituisce 'true' se il pagamento è stato effettuato puntualmente e 'false' se è stato effettuato in ritardo. Questo flag semplifica il calcolo e la visualizzazione del KPI del tasso di pagamento puntuale. Consente di filtrare e segmentare facilmente i dati per analizzare le caratteristiche delle fatture pagate in ritardo rispetto a quelle pagate puntualmente. Può aiutare a individuare schemi legati a specifici clienti, regioni o termini di pagamento che determinano ritardi. Perché è importante Semplifica la misurazione delle prestazioni indicando chiaramente ogni fattura come 'puntuale' o 'in ritardo' e supportando direttamente il KPI del tasso di pagamento puntuale. Dove reperirlo È un campo calcolato. La logica confronta il timestamp dell'attività 'Pagamento del cliente ricevuto' con il valore dell'attributo 'PaymentDueDate'. Esempi truefalse | |||
| Sistema di origine SourceSystem | Identifica il sistema di origine specifico dal quale sono stati estratti i dati. | ||
| Descrizione Questo attributo specifica l'origine dei dati, risultando particolarmente utile negli ambienti con più istanze SAP o altri sistemi integrati. In genere include l'ID del sistema e il numero del client. 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 i dati provenienti da più fonti vengono combinati per ottenere una visione complessiva del processo. Perché è importante Fornisce un contesto essenziale sull'origine dei dati, garantendo chiarezza negli ambienti multisistema e supportando la governance dei dati. Dove reperirlo In genere è un valore statico definito durante l'estrazione dei dati, che spesso combina l'ID del sistema (SY-SYSID) e il client (SY-MANDT). Esempi S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Stato del pagamento PaymentStatus | Lo stato attuale del pagamento della fattura, ad esempio Aperto, Pagato o Scaduto. | ||
| Descrizione Lo stato del pagamento offre una fotografia della posizione della fattura nel ciclo di vita del recupero crediti. Non corrisponde a un singolo campo SAP, ma viene ricavato verificando lo stato di compensazione del documento contabile corrispondente. Questo attributo è essenziale per la Dashboard sull'anzianità delle fatture aperte. Consente di segmentare tutte le fatture aperte in base allo stato e all'anzianità, aiutando il team di recupero crediti a definire efficacemente le priorità. Il monitoraggio delle transizioni tra gli stati permette inoltre di controllare il processo di recupero crediti stesso. Perché è importante Fornisce una visione chiara e immediata dello stato della fattura nel recupero crediti, fondamentale per gestire i crediti e definire le priorità delle attività di incasso. Dove reperirlo Derivato verificando lo stato di compensazione del documento contabile (VBRK-BELNR) in tabelle finanziarie come BSID (partite aperte) e BSAD (partite compensate). Esempi ApertoPagatoScadutoParzialmente pagato | |||
| Termini di pagamento PaymentTerms | Il codice che definisce le condizioni di pagamento, come il periodo concesso per effettuare il pagamento. | ||
| Descrizione I termini di pagamento sono condizioni predefinite concordate con il cliente, che stabiliscono quando deve essere pagata una fattura. Tra gli esempi figurano 'Net 30' (pagamento dovuto entro 30 giorni) o '2/10 Net 30' (sconto del 2% se il pagamento viene effettuato entro 10 giorni, altrimenti pagamento dovuto entro 30 giorni). L'analisi per termini di pagamento aiuta a valutarne l'efficacia. Correlando i diversi termini con il tempo effettivamente necessario per ricevere il pagamento, un'azienda può determinare quali condizioni favoriscono maggiormente la puntualità e ottimizzare i propri termini per migliorare il flusso di cassa. Perché è importante Definisce il calendario di pagamento concordato, consentendo di analizzare quali termini siano più efficaci nel garantire pagamenti puntuali da parte dei clienti. Dove reperirlo Tabella SAP: VBRK, campo: ZTERM Esempi Z030Z060ZB60 | |||
| Tipo di documento di fatturazione BillingDocumentType | Un 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 categorizza le transazioni all'interno del processo di fatturazione. Controlla il modo in cui il documento viene elaborato, compresi l'intervallo di numerazione e le regole di registrazione contabile. Questo attributo consente di filtrare il processo per analizzare tipologie specifiche di transazione. Ad esempio, è possibile creare una vista di processo separata solo per le note di credito, così da comprenderne i motivi e il flusso di processo per le rettifiche finanziarie, oppure analizzare separatamente le fatture standard e gli annullamenti per ottenere un quadro più chiaro del processo principale di fatturazione. Perché è importante Classifica le transazioni, consentendo un'analisi mirata di flussi documentali specifici, come fatture standard, note di credito o annullamenti. Dove reperirlo Tabella SAP: VBRK, campo: FKART Esempi F2G2S1L2 | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Il timestamp che indica quando i dati relativi a questo evento sono stati estratti o aggiornati l'ultima volta. | ||
| Descrizione Questo attributo registra la data e l'ora dell'ultimo prelievo dei dati dal sistema di origine. È un campo di metadati fondamentale per comprendere l'aggiornamento dei dati analizzati. Queste informazioni vengono utilizzate per verificare la recenza dell'analisi e gestire la pianificazione degli aggiornamenti dei dati. Assicurano che gli stakeholder siano consapevoli della tempestività dei dati quando prendono decisioni basate su Dashboard e insight di Process Mining. Perché è importante Indica l'aggiornamento dei dati, un elemento essenziale per considerare affidabile l'analisi e comprenderne la rilevanza rispetto allo stato attuale delle operazioni. Dove reperirlo Questo timestamp viene generato e applicato 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 | Il codice valuta dell'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 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 una valuta di reporting comune e di confrontare le prestazioni della fatturazione tra regioni con valute locali diverse. Perché è importante Fornisce il contesto essenziale per tutti i valori monetari, garantendo analisi e report finanziari accurati, soprattutto nelle attività multinazionali. Dove reperirlo Tabella SAP: VBRK, campo: WAERK Esempi USDEURGBP | |||
Attività di Order to Cash - Fatturazione ed emissione delle fatture
| Attività | Descrizione | ||
|---|---|---|---|
| Fattura chiusa | Questa attività indica lo stato finale di una fattura pagata correttamente. È funzionalmente equivalente a 'Pagamento applicato/riconciliato' e indica che il processo relativo alla fattura è completato. | ||
| Perché è importante Rappresenta il principale evento finale del percorso standard del processo. Misurare il tempo di ciclo complessivo fino a questo punto offre una visione completa del ciclo di vita end-to-end della fatturazione e dell'emissione delle fatture. Dove reperirlo Deducibile dallo stato della partita cliente nel documento contabile. Una partita è chiusa o 'compensata' quando i campi della data di compensazione (BSEG-AUGDT) e del documento di compensazione (BSEG-AUGBL) sono valorizzati. Acquisizione Deducibile dalla valorizzazione della data di compensazione (AUGDT) nella tabella BSEG/ACDOCA per la voce della fattura. Tipo di evento inferred | |||
| Fattura generata | Questa attività indica la creazione del documento di fatturazione nel sistema. È un evento esplicito acquisito quando un utente esegue una transazione come VF01 o quando un job in background crea la fattura, generando una nuova voce nella tabella di testata del documento di fatturazione. | ||
| Perché è importante Questo è il principale evento di avvio 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 generazione della fattura e individuare i ritardi iniziali del processo. Dove reperirlo Registrato nella tabella SAP S/4HANA VBRK (Billing Document: Header Data) al momento della creazione. La data di creazione (VBRK-ERDAT) e l'ora (VBRK-ERZET) fungono da 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à | Rappresenta la registrazione corretta del documento di fatturazione nel modulo di contabilità finanziaria. È una tappa fondamentale, poiché la fattura diventa una voce ufficiale dei crediti verso clienti e genera registrazioni nel libro mastro generale. | ||
| Perché è importante Questa attività conferma che la fattura è un documento finanziario legale. Il tempo che intercorre tra la generazione e la registrazione è un indicatore chiave delle prestazioni e mette in evidenza l'efficienza dell'elaborazione interna. Dove reperirlo 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, mentre la data di registrazione è BKPF-BUDAT. Acquisizione Acquisito dalla data di registrazione (BUDAT) del documento contabile nella tabella BKPF collegata al documento di fatturazione. Tipo di evento explicit | |||
| Pagamento applicato/riconciliato | Rappresenta il momento in cui il pagamento ricevuto dal cliente viene abbinato e utilizzato per compensare la partita aperta della fattura nel sottolibro dei crediti verso clienti. Questa attività completa la transazione dal punto di vista finanziario. | ||
| Perché è importante Misura l'efficienza del processo di applicazione degli incassi. I ritardi in questa fase possono fornire una rappresentazione errata dello stato effettivo dei conti cliente e generare attività non necessarie per i team di recupero crediti. Dove reperirlo Questo evento viene acquisito tramite la data di compensazione (BSEG-AUGDT) della voce del documento contabile relativa alla fattura originale. La data viene valorizzata quando un documento di compensazione compensa la partita. Acquisizione Acquisita dal campo della data di compensazione (AUGDT) nella tabella BSEG/ACDOCA per la voce della fattura. Tipo di evento explicit | |||
| Pagamento del cliente ricevuto | Questa attività indica la registrazione di un pagamento in entrata da parte di un cliente nel sistema finanziario. In questa fase il pagamento potrebbe non essere ancora associato a una fattura specifica, ma i fondi sono stati registrati. | ||
| Perché è importante Una tappa fondamentale per il calcolo dei Days Sales Outstanding (DSO). Indica che la liquidità è stata ricevuta, anche se la riconciliazione è ancora in sospeso. Dove reperirlo Acquisita dalla data di registrazione (BKPF-BUDAT) del documento di pagamento del cliente (in genere, tipo documento '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 apre una contestazione relativa a una fattura, che viene quindi registrata formalmente nel sistema. È necessario utilizzare il modulo SAP Dispute Management. | ||
| Perché è importante Evidenzia problemi di accuratezza della fatturazione, qualità dei prodotti o fornitura dei servizi che causano ritardi nei pagamenti. Analizzare le motivazioni delle contestazioni può aiutare ad affrontare le cause principali e migliorare la soddisfazione dei clienti. Dove reperirlo Registrato al momento della creazione di un caso di contestazione nelle tabelle 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 precedentemente creata viene annullata, operazione che in genere comporta la creazione di un documento di annullamento corrispondente. In questo modo vengono stornati la fattura originale e il relativo impatto contabile. | ||
| Perché è importante Indica rilavorazioni, correzioni o errori di fatturazione. Un'elevata frequenza di annullamenti segnala problemi significativi a monte nell'inserimento degli ordini di vendita o nella configurazione della fatturazione. Dove reperirlo Acquisita quando viene creato un documento di fatturazione di annullamento (ad esempio, tipo documento 'S1'). Questo nuovo documento in VBRK farà riferimento al numero della fattura originale nel campo VBRK-SFAKN. Acquisizione L'evento viene acquisito dalla data di creazione del documento di annullamento in VBRK che fa riferimento alla fattura originale. Tipo di evento explicit | |||
| Fattura inviata al cliente | Questa attività indica il momento in cui la fattura viene trasmessa al cliente, ad esempio tramite stampa, e-mail o EDI. Il meccanismo di acquisizione dipende dalla configurazione della gestione degli output in SAP. | ||
| Perché è importante L'inizio ufficiale del conteggio dei tempi di pagamento dal punto di vista del cliente. I ritardi nell'invio della fattura incidono direttamente sui Days Sales Outstanding (DSO) e sul flusso di cassa. Dove reperirlo Può essere registrato esplicitamente nelle tabelle di controllo degli output, come NAST per i metodi precedenti o il relativo equivalente in S/4HANA. Se non viene registrato esplicitamente, spesso si presume che avvenga contemporaneamente a "Invoice Posted To Accounting". Acquisizione Verifichi i log di elaborazione nelle tabelle di gestione degli output per individuare un timestamp associato al tipo di output della fattura. Tipo di evento explicit | |||
| Nota di credito creata | Questa attività rappresenta la creazione di una nota di credito, emessa a favore di un cliente per correggere un addebito eccessivo o riconoscere un credito per merci restituite. Spesso è collegata a una fattura originale. | ||
| Perché è importante Evidenzia i problemi che comportano rettifiche finanziarie dopo la fatturazione. L'analisi delle note di credito può far emergere errori di prezzo, problemi relativi ai prodotti o altre cause alla radice delle perdite di ricavi. Dove reperirlo Viene creata esplicitamente come nuovo documento di fatturazione (in VBRK) con uno specifico tipo di fatturazione per le note di credito (ad esempio, 'G2'). Spesso fa riferimento all'ordine di vendita o alla fattura originale. Acquisizione Acquisita dalla creazione di un documento di fatturazione in VBRK con un tipo di fatturazione per note di credito. Tipo di evento explicit | |||
| Registrazione fattura bloccata | Questo evento si verifica quando una fattura viene creata ma bloccata automaticamente per la registrazione nella contabilità finanziaria a causa di diversi motivi, come controlli del credito o incoerenze 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 immediatamente alla contabilità, ritardando l'intero ciclo di incasso. È un indicatore importante di problemi di qualità dei dati o di gestione del credito. Dove reperirlo Deducibile dal campo relativo allo stato di registrazione nella tabella di testata del documento di fatturazione (VBRK-RFBSK). Uno stato come "A" (documento di fatturazione bloccato per l'inoltro a FI) indica un blocco. Acquisizione Deducibile verificando il valore del campo relativo allo stato di registrazione (VBRK-RFBSK) subito dopo la generazione della fattura. Tipo di evento inferred | |||
| Rilavorazione della fatturazione identificata | Evento calcolato che identifica un ciclo di rilavorazione in cui una fattura è stata annullata e successivamente ne è stata generata una nuova per lo stesso ordine di vendita. Non si tratta di una singola transazione, ma di un insieme ricorrente di eventi. | ||
| Perché è importante Supporta direttamente il KPI del tasso di rilavorazione della fatturazione quantificando i casi di correzione. Aiuta a individuare le inefficienze e a misurare il costo della scarsa qualità nel processo di fatturazione. Dove reperirlo Questo schema viene calcolato identificando un evento 'Fattura annullata' seguito da un nuovo evento 'Fattura generata', entrambi riconducibili allo stesso documento di origine, ad esempio un numero di ordine di vendita. Acquisizione Derivato rilevando una sequenza di 'Fattura annullata' e 'Fattura generata' per lo stesso riferimento all'ordine di vendita. Tipo di evento calculated | |||
| Scadenza del pagamento raggiunta | Un evento calcolato che rappresenta la data in cui il pagamento della fattura è ufficialmente dovuto secondo le condizioni di pagamento concordate. Non è un evento transazionale, ma viene derivato dai dati della fattura. | ||
| Perché è importante Fornisce una base fondamentale per misurare la puntualità dei pagamenti e analizzare i comportamenti di pagamento dei clienti. Aiuta a distinguere i pagamenti puntuali da quelli scaduti. Dove reperirlo Calcolato sulla base della data di riferimento per il pagamento (BSEG-ZFBDT) e delle condizioni di pagamento memorizzate nella partita cliente del documento contabile. Acquisizione Derivato aggiungendo i giorni previsti dalle condizioni di pagamento alla data di riferimento del pagamento presente nella partita del documento contabile (BSEG). Tipo di evento calculated | |||
| Sollecito di pagamento emesso | Rappresenta l'invio al cliente di un sollecito di pagamento o di una comunicazione di messa in mora 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 determinare se i solleciti accelerano i pagamenti e quali livelli di sollecito producono il maggiore impatto. Dove reperirlo Registrato nelle tabelle della cronologia dei solleciti (MAHNV, MHND) quando viene eseguito il sollecito (transazione F150) per la partita aperta della fattura. Acquisizione Acquisito dalla data di esecuzione del sollecito registrata nelle tabelle della cronologia dei solleciti. Tipo di evento explicit | |||
Guide all'estrazione
Passaggi
- Prerequisiti: si assicuri di disporre di un account utente in SAP S/4HANA con le autorizzazioni necessarie per interrogare le viste Core Data Services (CDS). In particolare, Le occorre l'accesso in lettura a viste come I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase e I_DunningHistory.
- Accedere allo strumento di estrazione dei dati: acceda al Suo sistema SAP S/4HANA. Può utilizzare diversi strumenti per eseguire query SQL sulle viste CDS, 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 presume l'utilizzo di un client SQL standard.
- Identificare i parametri di sistema: prima di eseguire la query, individui i Company Code specifici e l'intervallo di date rilevante per la Sua analisi. È consigliabile iniziare con un ambito limitato, ad esempio gli ultimi 3-6 mesi di dati, per mantenere sotto controllo i tempi di esecuzione della query.
- Preparare la query SQL: copi la query SQL completa fornita nella sezione 'query' di questo documento nel client SQL scelto.
- Personalizzare i segnaposto: modifichi i valori segnaposto nella query. Sostituisca 'YYYY-MM-DD' con le date di inizio e fine desiderate. Sostituisca 'XXXX' con i Company Code di destinazione. Potrebbe inoltre dover modificare il segnaposto relativo ai tipi di documento delle note di credito, ad esempio 'G2', in base alla configurazione del Suo sistema.
- Eseguire la query: esegua la query SQL modificata sul database SAP S/4HANA. Il tempo di esecuzione varia in funzione del volume di dati compreso nell'intervallo selezionato.
- Esaminare i risultati: al termine della query, esamini l'output. Il set di risultati dovrebbe essere una tabella piatta, in cui ogni riga rappresenta una singola attività del processo di fatturazione. Questo è il Suo Event Log.
- Trasformare i dati, se necessario: la query è progettata per produrre un Event Log pulito. Verifichi tuttavia il formato dei timestamp, per assicurarsi che sia compatibile con il Suo strumento di Process Mining. La query utilizza ABAP_SYSTEM_UTCL_TO_TIMESTAMP per convertire i valori in un timestamp UTC standard, generalmente compatibile.
- Esportare l'Event Log: esporti l'intero set di risultati dal client SQL in un file CSV. Si assicuri che il file sia codificato in UTF-8 per evitare problemi con i caratteri.
- Caricare i dati in ProcessMind: carichi il file CSV generato nella piattaforma ProcessMind, associando le colonne del file, come InvoiceNumber, ActivityName ed EventTime, ai campi corrispondenti nello strumento.
Configurazione
- Intervallo di date: imposti le date di inizio e fine nella clausola WHERE della Common Table Expression (CTE) iniziale. Per un'analisi iniziale è consigliato un intervallo di 3-6 mesi, così da bilanciare il volume dei dati e le prestazioni. Il filtro si applica a BillingDocumentDate.
- Company Code: filtri uno o più valori CompanyCode per limitare l'estrazione alle entità giuridiche pertinenti. Si tratta di un filtro fondamentale per gestire l'ambito dei dati.
- Tipi di documento: la query include la logica per identificare le note di credito in base a BillingDocumentType. Deve configurare il segnaposto, ad esempio ('G2', 'CR'), con i tipi di documento specifici utilizzati nella Sua organizzazione per le note di credito.
- Prerequisiti: l'accesso alle viste CDS sottostanti è obbligatorio. Sono necessari ruoli e autorizzazioni specifici, assegnati dal team di sicurezza SAP. Inoltre, per attività come 'Customer Dispute Opened' o 'Payment Reminder Issued', i moduli SAP corrispondenti, SAP Dispute Management e SAP Financials Dunning, devono essere attivamente utilizzati nel Suo sistema.
- Prestazioni: la query utilizza più join e union. Per dataset molto grandi, ad esempio diversi anni di dati, valuti l'esecuzione negli orari di minore utilizzo oppure applichi filtri più restrittivi per limitare il caricamento iniziale dei dati.
a 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
- Confermi che sia disponibile l'accesso diretto in lettura allo schema SAP HANA contenente le tabelle di fatturazione e le tabelle finanziarie correlate. Richieda al responsabile del sistema il nome dello schema, i dettagli di connessione, l'intervallo di date autorizzato, l'ambito dei Company Code, i tipi di documento di fatturazione e gli eventuali filtri per cliente o regione. Sostituisca nella query esclusivamente i segnaposto relativi alla connessione e ai filtri.
- Confermi le origini dati SAP S/4HANA pertinenti e le relative mappature dei campi nel sistema di destinazione. La query utilizza VBRK e VBRP per i dati di fatturazione e richiede origini configurate per contabilità, gestione degli output, gestione delle contestazioni, solleciti di pagamento, pagamenti in entrata, compensazione e relazioni tra documenti. Sostituisca i segnaposto tra parentesi quadre solo dopo averli convalidati rispetto al dizionario dati del sistema.
- Configuri il periodo di estrazione utilizzando timestamp di inizio inclusivi e timestamp di fine esclusivi. Per la prima esecuzione è consigliato un periodo di 3-6 mesi. Limiti l'estrazione per Company Code e, ove opportuno, per tipo di fatturazione, così da controllare il volume ed evitare di combinare processi di fatturazione non correlati.
- Esegua la query con un utente del database HANA in 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, vengono 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. Confermi che InvoiceNumber, ActivityName ed EventTime siano valorizzati per ogni riga.
- Convalidi la semantica e le relazioni degli eventi. Confronti le righe Invoice Generated con i dati di creazione delle testate 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 dei pagamenti con i documenti contabili e le righe di compensazione con le partite compensate delle fatture. Esamini tutte le sezioni dipendenti dai segnaposto prima dell'utilizzo 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 si assicuri che i valori ActivityName corrispondano esattamente ai nomi delle attività richiesti. Ordini per InvoiceNumber ed EventTime, applicando un ordinamento secondario deterministico quando più eventi condividono 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, quando disponibili, quindi carichi il file tramite il processo di importazione ProcessMind configurato ed esegua un controllo finale del numero di righe e di attività.
Configurazione
- Intervallo di date: inizi con un periodo di 3-6 mesi. Utilizzi un timestamp di inizio inclusivo e un timestamp di fine esclusivo per evitare eventi duplicati tra esecuzioni incrementali.
- Identificativo del caso: utilizzi InvoiceNumber dalla testata del documento di fatturazione. Lo conservi come stringa, poiché i numeri dei documenti SAP possono contenere zeri iniziali.
- Attività obbligatorie: 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 Company Code, tipo di documento di fatturazione, organizzazione commerciale, cliente, regione e date solo dopo aver confermato i campi corrispondenti e l'ambito operativo nel sistema di destinazione. Non presuma che ogni tipo di documento di fatturazione segua lo stesso processo contabile o di output.
- Configurazione delle origini: VBRK e VBRP sono le origini principali per la fatturazione. Le origini relative a contabilità, output, contestazioni, solleciti, pagamenti, compensazione e flusso documentale devono essere configurate in base alla release SAP S/4HANA implementata e ai moduli abilitati. Sostituisca i riferimenti alle origini tra parentesi quadre con oggetti e campi convalidati.
- Eventi calcolati: Payment Due Date Reached deriva dalle condizioni di pagamento e dai dati sulla scadenza. Billing Rework Identified deriva dai pattern di annullamento e successiva generazione di una fattura. Si tratta di righe di evento generate da SQL, non di record transazionali nativi.
- Prestazioni: applichi i filtri per data, Company Code, tipo di fatturazione e numero documento in ogni query di origine. Selezioni solo le colonne necessarie, eviti join non limitati con tabelle contabili di grandi dimensioni, elabori il periodo in blocchi 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 piccola finestra di sovrapposizione per acquisire i record di output, pagamento, contestazione e compensazione arrivati in ritardo, quindi elimini i duplicati utilizzando InvoiceNumber, ActivityName ed EventTime insieme alla chiave del documento di origine pertinente.
- Autorizzazioni: l'utente di estrazione richiede autorizzazioni di lettura per gli oggetti e i campi dello schema HANA selezionati. Confermi che l'accesso diretto al database sia consentito dalle policy di sicurezza dell'organizzazione e che siano rispettati i requisiti per la gestione dei dati personali o dei clienti.
- Prerequisiti funzionali: i dati relativi a gestione degli output, integrazione contabile, gestione delle contestazioni, solleciti, pagamenti in entrata e compensazione sono disponibili solo se i relativi componenti sono configurati e utilizzati nel sistema. L'assenza di moduli o record di origine comporta attività mancanti, non eventi dedotti.
- Fuso orario: standardizzi i timestamp nel fuso orario richiesto da ProcessMind. Documenti se i timestamp di origine sono memorizzati in UTC, nell'ora locale del sistema o in un altro fuso orario configurato.
a 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 a iniziare?
Utilizzi questo Template per accelerare la preparazione dei dati e iniziare a ottimizzare il processo di Order to Cash, fatturazione ed emissione delle fatture. Inizi oggi stesso a trasformare i dati SAP S/4HANA in insight concreti.
Ottimizzi la fatturazione Order to Cash per accelerare del 30% il flusso di cassa
Elimini le inefficienze e riduca del 30% la durata del ciclo di fatturazione, a partire da oggi.
Non è richiesta alcuna carta di credito. Inizi in pochi minuti.