Il template dei dati per Record to Report - Registrazione contabile
Il template dei dati per Record to Report - Registrazione contabile
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni pratiche per l’estrazione
Attributi di Record to Report - Registrazione contabile
| Nome | Descrizione | ||
|---|---|---|---|
| Attività ActivityName | Nome dell’attività aziendale svolta in un determinato momento del processo di registrazione contabile. | ||
| Descrizione L’attività rappresenta un passaggio o un evento specifico nel ciclo di vita di una registrazione contabile, come «Registrazione contabile creata», «Registrazione contabile inviata per la revisione» o «Registrazione contabile contabilizzata». In genere, le attività vengono ricavate dai log delle modifiche, dagli aggiornamenti di stato o dai codici transazione registrati nel sistema. Analizzare le attività consente di visualizzare il flusso del processo, individuare i percorsi più comuni e rilevare le deviazioni dalla procedura standard. È fondamentale per calcolare metriche come la frequenza delle attività, i tempi di attesa tra un passaggio e l’altro e i tassi di conformità. Perché è importante Definisce i passaggi del processo e consente di visualizzare le mappe di processo e analizzare gli schemi dei flussi di lavoro. Dove reperirli Ricavata da diverse fonti, tra cui i campi di stato nelle tabelle di testata e delle singole voci, ad esempio BKPF-BSTAT, i log dei documenti delle modifiche (CDHDR/CDPOS) e i log del flusso di lavoro. Esempi Registrazione contabile creataRegistrazione contabile parcheggiataRegistrazione contabile inviata per la revisioneRegistrazione contabile approvataRegistrazione contabile contabilizzata | |||
| Data e ora dell’evento EventTime | Data e ora che indicano quando si è svolta una specifica attività relativa alla registrazione contabile. | ||
| Descrizione La data e l’ora dell’evento indicano il momento preciso in cui un’attività aziendale è stata eseguita e registrata nel sistema. Ogni attività di un caso ha la propria data e ora, che insieme formano una sequenza cronologica di eventi. Questo attributo è fondamentale per tutte le analisi di processo basate sul tempo. Viene utilizzato per calcolare i tempi di ciclo, la durata tra le attività e i tempi di attesa, oltre che per comprendere la distribuzione temporale del lavoro. Date e ore accurate sono essenziali per creare un modello di processo affidabile e calcolare indicatori chiave di prestazione come il tempo di ciclo dell’approvazione. Perché è importante Fornisce l’ordine cronologico degli eventi, indispensabile per calcolare tutte le metriche basate sulla durata e comprendere la sequenza temporale del processo. Dove reperirli Ricavata dai log dei documenti delle modifiche (CDHDR-UDATE, CDHDR-UTIME), dai log del flusso di lavoro o dai campi di data e ora di creazione o inserimento in tabelle come BKPF (CPUDT, CPUTM). Esempi 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| ID della registrazione contabile JournalEntryId | Identificativo univoco di una registrazione contabile, utilizzato come identificativo principale del caso nel processo. | ||
| Descrizione L’ID della registrazione contabile è un numero univoco assegnato a ogni documento contabile al momento della creazione in SAP S/4HANA. È essenziale per monitorare l’intero ciclo di vita della registrazione, dalla creazione o dal parcheggio iniziale, passando per i flussi di lavoro di approvazione, fino alla contabilizzazione finale e all’eventuale storno o compensazione. Nell’analisi di Process Mining, questo ID collega tutte le attività correlate in un unico caso. Raggruppando gli eventi in base a un ID comune della registrazione contabile, gli analisti possono ricostruire il flusso del processo dall’inizio alla fine, misurare i tempi di ciclo e individuare variazioni o colli di bottiglia per ogni singola transazione finanziaria. È l’attributo fondamentale su cui si basa l’intera vista del processo. Perché è importante Questo identificativo collega tutti i passaggi correlati del processo e consente di analizzare l’intero percorso di ogni registrazione contabile. Dove reperirli Si tratta di una chiave composta, generalmente ottenuta concatenando il codice società (BKPF-BUKRS), il numero del documento (BKPF-BELNR) e l’esercizio fiscale (BKPF-GJAHR). Esempi 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Codice società CompanyCode | Identificativo univoco della società o entità giuridica per cui viene registrata la scrittura contabile. | ||
| Descrizione Il codice società è un’unità organizzativa fondamentale in SAP Financials e rappresenta un’entità giuridica indipendente per la quale vengono redatti i bilanci. Ogni scrittura contabile è assegnata a un codice società specifico. Questo attributo è essenziale per segmentare e confrontare le prestazioni del processo nelle diverse aree dell’organizzazione. Gli analisti possono usarlo per filtrare la vista del processo in base a una specifica entità giuridica, confrontare i tassi di rifiuto tra codici società o individuare variazioni del processo legate a una determinata area geografica. Perché è importante Consente di filtrare e confrontare il processo di registrazione contabile tra le diverse entità giuridiche o unità aziendali dell’organizzazione. Dove reperirli Tabella BKPF di SAP S/4HANA, campo BUKRS (codice società). Esempi 10001710US01 | |||
| Data di registrazione PostingDate | Data in cui la registrazione contabile viene contabilizzata nella contabilità generale, determinando il periodo finanziario di riferimento. | ||
| Descrizione La data di registrazione determina il periodo fiscale in cui la transazione compare nei bilanci. È una data fondamentale per la contabilità e può essere diversa da quella in cui il documento è stato creato o inserito nel sistema. Nel Process Mining, la data di registrazione viene utilizzata per analisi per coorte basate sul tempo, ad esempio per confrontare i processi di chiusura di fine mese o analizzare l’andamento delle prestazioni nei diversi periodi finanziari. Serve anche a misurare i ritardi tra la creazione della registrazione e la sua effettiva contabilizzazione. Perché è importante È fondamentale per inquadrare i dati finanziari e analizzare le prestazioni del processo in specifici periodi contabili, ad esempio a fine mese o a fine anno. Dove reperirli Tabella BKPF di SAP S/4HANA, campo BUDAT (data di registrazione nel documento). Esempi 2023-10-312023-11-012024-02-29 | |||
| Importo in valuta locale AmountInLocalCurrency | Valore totale della registrazione contabile espresso nella valuta locale del codice società. | ||
| Descrizione Questo attributo rappresenta il valore finanziario della registrazione contabile. In genere corrisponde alla somma dei valori assoluti di tutte le righe dare o avere del documento, convertita nella valuta locale del codice società. L’analisi per importo consente di segmentare il processo in base all’impatto finanziario. Per esempio, le registrazioni di importo elevato possono richiedere un processo di approvazione più rigoroso rispetto a quelle di importo ridotto. Aiuta a dare priorità agli interventi di miglioramento sui processi relativi alle transazioni che comportano i rischi finanziari maggiori. Perché è importante Indica il valore finanziario della registrazione e consente di analizzare come cambia il comportamento del processo in base all’importo coinvolto. Dove reperirli Calcolato sommando gli importi della tabella delle righe BSEG (campo DMBTR) per una determinata registrazione contabile (BELNR) e convertendo il risultato in un valore positivo. Esempi 1500.75125000.0050.20 | |||
| Tipo di registrazione contabile JournalEntryType | Classifica la registrazione contabile in base alla sua finalità aziendale, ad esempio una registrazione di cespiti, una fattura fornitore o una registrazione di contabilità generale. | ||
| Descrizione Il tipo di registrazione contabile, denominato in SAP tipo documento, è una chiave che classifica i documenti contabili. Determina aspetti quali l’intervallo di numerazione assegnato al documento e i tipi di conto ammessi per la registrazione. Analizzare il processo in base al tipo di registrazione è fondamentale per comprendere i comportamenti specifici dei diversi contesti. Per esempio, il processo di approvazione di un semplice accantonamento (tipo SA) può essere molto più lineare di quello relativo a una complessa acquisizione di cespiti (tipo AA). Questa dimensione è fondamentale per la Dashboard «Conformità per tipo di registrazione». Perché è importante Classifica le registrazioni in base al contesto aziendale e consente di analizzare le variazioni e le prestazioni del processo per i diversi tipi di transazioni finanziarie. Dove reperirli Tabella BKPF di SAP S/4HANA, campo BLART (tipo documento). Esempi SAKRAA | |||
| Utente che ha creato la registrazione CreatedByUser | ID utente della persona che ha creato la registrazione contabile. | ||
| Descrizione Questo attributo memorizza l’identificativo univoco dell’utente che ha avviato il processo di registrazione contabile creando il documento iniziale. Può trattarsi di un contabile, di un utente aziendale o dell’ID di un sistema per le registrazioni automatiche. Analizzare il processo in base a chi ha creato la registrazione aiuta a individuare schemi ricorrenti associati a specifici utenti o team. Può far emergere esigenze di formazione, ad esempio se alcuni utenti registrano più rifiuti, oppure mettere in evidenza le persone con i risultati migliori. È essenziale per la Dashboard «Attività e produttività degli utenti». Perché è importante Associa le attività del processo a utenti specifici, consentendo di analizzare le prestazioni, bilanciare i carichi di lavoro e individuare opportunità di formazione. Dove reperirli Tabella BKPF di SAP S/4HANA, campo USNAM (nome utente). Esempi ABROWNCJONESBATCH_USER | |||
| Codice transazione TransactionCode | Codice transazione SAP utilizzato per creare o modificare la registrazione contabile. | ||
| Descrizione Il codice transazione (T-Code) è una scorciatoia che identifica una specifica funzione o un programma in SAP. Per le registrazioni contabili, i diversi T-Code possono indicare come è stata creata la registrazione: per esempio, FB01 per una registrazione manuale in contabilità generale, FV50 per la registrazione provvisoria o un codice automatico per le registrazioni generate dal sistema. Questo attributo indica chiaramente se un’attività è stata eseguita manualmente da un utente o automaticamente dal sistema. È fondamentale per calcolare il KPI del tasso di registrazioni manuali e individuare opportunità di automazione. Perché è importante Indica come è stata elaborata una registrazione, ad esempio manualmente o automaticamente, e aiuta ad analizzare l’automazione e a comprendere le variazioni del processo. Dove reperirli Tabella BKPF di SAP S/4HANA, campo TCODE (codice transazione). Esempi FB01FV50F-02 | |||
| È una registrazione manuale IsManualPosting | Indicatore booleano che segnala se la registrazione contabile è stata contabilizzata manualmente da un utente. | ||
| Descrizione Questo attributo identifica le registrazioni contabili inserite con l’intervento manuale di un utente, anziché automaticamente tramite un processo pianificato o un’interfaccia di sistema. In genere viene ricavato dal codice transazione utilizzato per contabilizzare il documento. L’indicatore serve a calcolare il KPI del tasso di registrazioni manuali e aiuta le organizzazioni a monitorare i progressi nell’automazione del processo Record to Report. Filtrando le registrazioni manuali, gli analisti possono individuare gli scenari che richiedono ancora l’intervento umano e valutarne il potenziale di automazione. Perché è importante Distingue le registrazioni eseguite da persone da quelle gestite dal sistema, un aspetto fondamentale per misurare il livello di automazione e individuare nuove opportunità. Dove reperirli È un attributo calcolato in base a TransactionCode. L’indicatore viene impostato su «true» se il codice transazione rientra in un elenco predefinito di codici manuali, ad esempio «FB01» e «F-02». Esempi truefalse | |||
| È una rilavorazione IsRework | Indicatore booleano che segnala se la registrazione contabile è stata rilavorata, ad esempio dopo una correzione a seguito di un rifiuto. | ||
| Descrizione Questo attributo calcolato segnala le registrazioni contabili che si sono discostate dal percorso ottimale del processo. In genere viene impostato su true se nel caso si verifica un’attività come «Registrazione contabile rifiutata» o «Registrazione contabile corretta». L’indicatore semplifica l’analisi dell’efficienza del processo. Consente di calcolare rapidamente il KPI del tasso di rilavorazione e di confrontare direttamente i tempi di ciclo e i costi dei casi con e senza rilavorazioni. Individuare i fattori che causano le rilavorazioni è uno degli obiettivi principali di molte iniziative di miglioramento dei processi. Perché è importante Segnala i casi che hanno richiesto correzioni o passaggi aggiuntivi, facilitando la quantificazione delle inefficienze del processo e l’analisi delle relative cause profonde. Dove reperirli È un attributo calcolato in base alla sequenza delle attività di un caso. Viene impostato su «true» se è presente un’attività come «Registrazione contabile rifiutata». Esempi truefalse | |||
| Esercizio fiscale FiscalYear | Esercizio fiscale a cui appartiene la registrazione contabile. | ||
| Descrizione L’esercizio fiscale è parte della chiave univoca di una registrazione contabile, insieme al codice società e al numero del documento. Rappresenta l’anno finanziario a cui il documento si riferisce. In fase di analisi, l’esercizio fiscale viene utilizzato per analizzare gli andamenti nel lungo periodo e garantire l’univocità dell’identificativo del caso. Confrontare le metriche del processo tra esercizi fiscali diversi può rivelare miglioramenti o peggioramenti delle prestazioni nel tempo. Perché è importante È un elemento fondamentale per identificare in modo univoco i documenti e consente di analizzare le prestazioni del processo da un anno all’altro. Dove reperirli Tabella BKPF di SAP S/4HANA, campo GJAHR (esercizio fiscale). Esempi 202320242022 | |||
| Motivo dello storno ReversalReason | Codice che indica il motivo per cui una registrazione contabile già contabilizzata è stata stornata. | ||
| Descrizione Se una registrazione contabile già contabilizzata è errata, non può essere eliminata: deve essere stornata con un nuovo documento. Il codice del motivo dello storno spiega perché è stata eseguita questa operazione, ad esempio per una data o un importo di registrazione errati. Analizzare i motivi degli storni aiuta a individuare le cause profonde degli errori nel processo Record to Report. La frequenza elevata di un determinato motivo può indicare problemi sistemici, come una formazione inadeguata o carenze nei controlli, da affrontare per migliorare la qualità al primo tentativo. Perché è importante Aiuta a individuare le cause profonde degli errori che portano agli storni, fornendo indicazioni utili per ridurre le rilavorazioni e migliorare la qualità del processo. Dove reperirli Tabella BKPF di SAP S/4HANA, campo STGRD (motivo dello storno). Esempi 010205 | |||
| Ora di fine EndTime | Data e ora in cui l’attività è stata completata. | ||
| Descrizione L’ora di fine indica il completamento di un’attività. In molti Event Log, l’ora di inizio e quella di fine coincidono, perché l’attività rappresenta un evento istantaneo. Per le attività di cui è possibile misurare la durata, come la revisione attiva di un documento da parte di un utente, questo attributo può invece registrare il tempo impiegato. Disporre di un’ora di fine distinta consente di calcolare con maggiore precisione i tempi di elaborazione delle attività e i tempi di attesa. In questo modo è possibile distinguere il tempo dedicato effettivamente a un’attività da quello trascorso in attesa in una coda. Perché è importante Consente di calcolare con precisione i tempi di elaborazione delle attività, distinguendo il tempo di lavoro effettivo da quello di attesa. Dove reperirli Per gli eventi atomici coincide in genere con StartTime. Per le attività con una durata, può provenire dai log del flusso di lavoro oppure essere calcolata in base agli eventi successivi. Esempi 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Sistema di origine SourceSystem | Identifica il sistema di origine da cui sono stati estratti i dati delle registrazioni contabili. | ||
| Descrizione Questo attributo specifica il sistema di registrazione da cui provengono i dati della registrazione contabile. Nelle aziende che utilizzano più istanze ERP o combinano sistemi legacy e moderni, consente di distinguere le diverse origini dei dati. In fase di analisi, può essere utilizzato per confrontare le prestazioni del processo tra sistemi diversi o per filtrare i dati relativi a una specifica origine. È importante per la governance dei dati e per comprenderne il contesto. Perché è importante Fornisce informazioni sull’origine dei dati, fondamentali per analizzare e confrontare correttamente i processi in ambienti con più sistemi. Dove reperirli In genere è un valore statico aggiunto durante l’estrazione dei dati, che identifica la specifica istanza SAP S/4HANA, ad esempio tramite SID o nome del sistema logico. Esempi S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Stato del documento DocumentStatus | Stato corrente di elaborazione della registrazione contabile, ad esempio provvisoria, contabilizzata o compensata. | ||
| Descrizione Lo stato del documento indica in quale fase del ciclo di vita si trova la registrazione contabile. Per esempio, un documento «provvisorio» è stato salvato ma non ancora contabilizzato nella contabilità generale, mentre un documento «contabilizzato» è definitivo. Analizzare lo stato aiuta a comprendere il flusso di lavoro e a individuare i colli di bottiglia. Un numero elevato di documenti che rimangono a lungo nello stato «provvisorio» o «in attesa di approvazione» può segnalare inefficienze nel processo. Lo stato è anche una fonte importante per ricavare le attività del processo. Perché è importante Mostra a che punto del ciclo di vita si trova una registrazione contabile e aiuta a individuare code e colli di bottiglia. Dove reperirli Tabella BKPF di SAP S/4HANA, campo BSTAT (stato del documento). Esempi VAB | |||
| Tempo di ciclo dell’approvazione ApprovalCycleTime | Tempo trascorso dall’invio della registrazione contabile per l’approvazione fino alla sua approvazione o al suo rifiuto. | ||
| Descrizione Questa metrica calcolata misura specificamente la durata della fase di approvazione. Rileva il tempo tra l’attività «Registrazione contabile inviata per la revisione» e la successiva attività «Registrazione contabile approvata» o «Registrazione contabile rifiutata». Questo KPI è fondamentale per individuare i colli di bottiglia nel flusso di lavoro di approvazione. Tempi di ciclo dell’approvazione elevati possono ritardare notevolmente l’intero processo. Analizzare la metrica per approvatore, codice società o tipo di registrazione contabile può far emergere aree specifiche da migliorare. Perché è importante Isola la durata della fase di approvazione e aiuta a individuare e risolvere i colli di bottiglia nel flusso di lavoro di revisione e approvazione. Dove reperirli Calcolato misurando la differenza di tempo tra l’evento «Registrazione contabile inviata per la revisione» e l’evento «Registrazione contabile approvata» o «Registrazione contabile rifiutata». Esempi 1 giorno e 2 ore4 ore e 25 minuti5 giorni e 0 ore | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Data e ora dell’ultimo aggiornamento dei dati di questo record dal sistema di origine. | ||
| Descrizione Questo attributo registra la data e l’ora dell’estrazione o dell’aggiornamento più recente dei dati dal sistema di origine. Indica quanto sono aggiornati i dati analizzati. Conoscere l’ora dell’ultimo aggiornamento è importante per valutare l’attualità dell’analisi del processo. Aiuta a interpretare correttamente le Dashboard e i KPI, chiarendo se si tratta di dati quasi in tempo reale o di un’istantanea relativa a un periodo precedente. Perché è importante Indica quanto sono aggiornati i dati, così chi li consulta può valutare l’attualità dell’analisi del processo. Dove reperirli È un attributo di metadati, generalmente generato e associato a ogni record durante il processo di acquisizione dei dati. Esempi 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Utente approvatore ApproverUser | ID utente della persona che ha approvato o rifiutato la registrazione contabile. | ||
| Descrizione Questo attributo identifica l’utente responsabile della revisione e della decisione su una registrazione contabile inviata. Nei flussi di lavoro di approvazione a più livelli, una singola registrazione contabile può avere diversi approvatori. Queste informazioni sono essenziali per analizzare nel dettaglio il processo di approvazione. Aiutano a misurare il carico di lavoro dei diversi approvatori, calcolare i tempi di approvazione individuali e individuare i colli di bottiglia nella catena di approvazione. Sono direttamente utili per la Dashboard «Attività e produttività degli utenti». Perché è importante Identifica la persona responsabile dell’approvazione e consente di analizzare i carichi di lavoro, le prestazioni e i colli di bottiglia del processo di approvazione. Dove reperirli Ricavato dai log del flusso di lavoro, ad esempio SWW_WI2OBJ e SWWLOG, o dalle tabelle dei documenti di modifica (CDHDR/CDPOS), individuando chi ha eseguito la fase di approvazione. Esempi DMILLERFWHITEKCHEN | |||
Attività di Record to Report - Registrazione contabile
| Attività | Descrizione | ||
|---|---|---|---|
| Registrazione contabile approvata | La registrazione contabile riceve l’approvazione finale da un responsabile autorizzato, che ne conferma la validità e l’accuratezza. Questa attività è l’ultimo passaggio prima che il documento possa essere registrato nel libro mastro generale. | ||
| Perché è importante È una tappa fondamentale che conclude il ciclo di approvazione. Il tempo necessario per raggiungerla costituisce una parte significativa della durata complessiva del processo ed è un indicatore importante dell’efficienza degli approvatori. Dove reperirli L’evento viene dedotto da un log del flusso di lavoro che mostra il passaggio di approvazione finale o una modifica dello stato del documento. L’ID utente dell’approvatore e la data e l’ora possono essere ricavati dai dati del flusso di lavoro o dai log delle modifiche. Acquisizione Individui la data e l’ora del passaggio di approvazione finale nei log del flusso di lavoro oppure la modifica dello stato in «Approvato» nei documenti delle modifiche. Tipo di evento inferred | |||
| Registrazione contabile compensata | Una voce aperta di una registrazione contabile viene compensata da un’altra registrazione, ad esempio quando un pagamento salda una fattura. Questa attività segna la riconciliazione di specifiche voci e la loro chiusura. | ||
| Perché è importante Per molte registrazioni contabili, in particolare quelle relative a conti transitori o gestiti per partite aperte, questa attività rappresenta la fase finale della riconciliazione. Analizzare il tempo che intercorre tra la registrazione e la compensazione aiuta a misurare l’efficienza della riconciliazione. Dove reperirli L’evento viene dedotto dalla tabella delle singole voci (BSEG o vista ACDOCA). Quando una voce viene compensata, i campi della data di compensazione (AUGDT) e del documento di compensazione (AUGBL) vengono compilati. Acquisizione Utilizzi la data di compensazione della singola voce (BSEG-AUGDT) come data e ora dell’evento. Tipo di evento inferred | |||
| Registrazione contabile contabilizzata | La registrazione contabile viene registrata ufficialmente nel libro mastro generale e incide sul bilancio dell’azienda. Da questo momento, il documento diventa una registrazione finanziaria permanente. | ||
| Perché è importante È il principale traguardo che segna la fine del ciclo di elaborazione centrale. Analizzare il volume delle registrazioni contabilizzate e il tempo necessario per arrivare a questa fase è fondamentale per le metriche di Process Mining. Dove reperirli Si tratta di un evento esplicito, indicato dalla data di registrazione (BUDAT) nella tabella BKPF. Un documento contabilizzato ha il campo dello stato del documento (BSTAT) vuoto, a differenza dei documenti parcheggiati («V») o sospesi («D»). Acquisizione Utilizzi la data di registrazione (BKPF-BUDAT) e la data di inserimento (BKPF-CPUDT) per indicare la data e l’ora dell’evento. Un valore BKPF-BSTAT vuoto indica che il documento è stato contabilizzato. Tipo di evento explicit | |||
| Registrazione contabile creata | Questa attività segna la creazione iniziale di un documento di registrazione contabile nel sistema. Il record viene creato nella tabella di testata (BKPF), ma non è ancora stato registrato nel libro mastro generale. È il punto di partenza del ciclo di vita della registrazione contabile. | ||
| Perché è importante Questo è l’evento di inizio principale del processo. Analizzare il tempo che intercorre tra questo evento e la registrazione è fondamentale per misurare il tempo di ciclo complessivo e individuare ritardi iniziali nell’inserimento dei dati. Dove reperirli Questo evento può essere rilevato direttamente nella tabella SAP BKPF utilizzando i campi della data di creazione (CPUDT) e dell’ora di creazione (CPUTM) per un determinato numero di documento (BELNR). Acquisizione Utilizzi BKPF-CPUDT e BKPF-CPUTM per indicare la data e l’ora dell’evento. Tipo di evento explicit | |||
| Registrazione contabile inviata per la revisione | Chi ha creato la registrazione contabile invia formalmente il documento al flusso di lavoro di revisione e approvazione. Questa attività segna il passaggio dall’inserimento dei dati al processo formale di controllo e avvia il ciclo di approvazione. | ||
| Perché è importante Questo evento segna l’inizio del tempo di ciclo dell’approvazione. Misurare il tempo che intercorre da questo momento fino all’approvazione o al rifiuto finale aiuta a isolare i colli di bottiglia nelle fasi di revisione e approvazione. Dove reperirli Spesso l’evento viene rilevato nei log del flusso di lavoro (tabelle SWW_WIHEAD, SWWLOG) collegati all’oggetto aziendale. Può anche essere dedotto da una modifica dello stato in un campo personalizzato della testata del documento (BKPF). Acquisizione Data e ora di creazione dell’elemento del flusso di lavoro oppure modifica di un campo di stato in «Inviato» o «In revisione». Tipo di evento inferred | |||
| Storno della registrazione contabile elaborato | Una registrazione contabile già contabilizzata viene stornata creando un nuovo documento con registrazioni inverse. Questa operazione, esplicita e verificabile, serve a correggere gli errori nei documenti contabilizzati. | ||
| Perché è importante Gli storni indicano che è stato commesso un errore in un documento contabilizzato. Un tasso di storno elevato segnala problemi sottostanti nel processo di approvazione o nella qualità dell’inserimento dei dati; monitorarlo aiuta a migliorare l’accuratezza al primo tentativo. Dove reperirli Lo storno è un evento esplicito. La testata del nuovo documento di storno (BKPF) contiene un riferimento al documento originale nel campo Numero documento stornato (STBLG). La data di registrazione del nuovo documento indica il momento dell’evento. Acquisizione Individui i documenti per cui BKPF-STBLG è compilato. La data dell’evento corrisponde alla data di registrazione del documento di storno. Tipo di evento explicit | |||
| Documentazione di supporto allegata | Un utente allega alla registrazione contabile uno o più documenti di supporto, come fatture o fogli di calcolo. In genere, questi documenti forniscono prove e contesto per la transazione finanziaria durante la revisione e l’audit. | ||
| Perché è importante Allegare la documentazione prima della revisione è fondamentale per la conformità e l’efficienza delle approvazioni. Questa attività consente di misurare il rispetto delle procedure documentali e il relativo impatto sui tempi del ciclo di approvazione. Dove reperirli In genere, l’evento viene dedotto verificando la data e l’ora di creazione degli allegati collegati tramite Generic Object Services (GOS). La tabella SRGBTBREL collega l’oggetto aziendale, ad esempio un documento BKPF, all’allegato. Acquisizione Interroghi le tabelle degli allegati GOS, ad esempio SRGBTBREL, per individuare i collegamenti all’oggetto BKPF e utilizzi la data e l’ora di creazione dell’allegato. Tipo di evento inferred | |||
| Registrazione contabile corretta | Dopo che una registrazione contabile è stata rifiutata o restituita per essere modificata, l’utente la corregge. Questa attività rappresenta il lavoro di rilavorazione necessario per risolvere i problemi rilevati durante la revisione prima di inviare nuovamente il documento. | ||
| Perché è importante Questa attività quantifica i cicli di rilavorazione. Analizzare la frequenza e la durata delle correzioni aiuta a individuare le fonti di inefficienza e le opportunità di formazione e chiarimento delle procedure. Dove reperirli L’evento può essere dedotto monitorando la data dell’ultima modifica (AEDAT) nella tabella BKPF per un documento che si trovava precedentemente nello stato «Rifiutato». I documenti delle modifiche forniscono dettagli più specifici sulle variazioni apportate. Acquisizione Utilizzi la data e l’ora delle intestazioni dei documenti delle modifiche (CDHDR-UDATE) per le modifiche apportate dopo un evento di rifiuto. Tipo di evento inferred | |||
| Registrazione contabile modificata dopo la contabilizzazione | Dopo che una registrazione contabile è stata contabilizzata nel libro mastro generale, un utente modifica un insieme limitato di campi. Sebbene la maggior parte dei dati finanziari non sia modificabile dopo la contabilizzazione, è possibile cambiare alcuni campi, come il testo o le assegnazioni. | ||
| Perché è importante Questa attività è un indicatore critico ai fini della conformità. Le modifiche successive alla contabilizzazione possono segnalare tentativi di alterare le registrazioni e devono essere monitorate attentamente per prevenire le frodi e garantire l’integrità dei dati. Dove reperirli L’evento può essere dedotto in modo affidabile dalle tabelle dei documenti delle modifiche (CDHDR e CDPOS). Una voce in CDHDR relativa al numero del documento, con una data di modifica successiva alla data di registrazione, indica una modifica successiva alla contabilizzazione. Acquisizione Individui i record in CDHDR in cui la data e l’ora della modifica (UDATE/UTIME) sono successive alla data di registrazione del documento (BKPF-BUDAT). Tipo di evento inferred | |||
| Registrazione contabile parcheggiata | Un utente salva una registrazione contabile incompleta senza registrarla, così da poterla completare o rivedere in un secondo momento. Questa azione esplicita crea un record di testata del documento con stato «parcheggiato», mantenendolo non registrato. | ||
| Perché è importante Il parcheggio è un passaggio comune prima dell’invio. Monitorare la durata dello stato parcheggiato aiuta a individuare ritardi nel completamento e nella preparazione dei dati, prima dell’avvio della revisione e dell’approvazione formali. Dove reperirli Nella tabella BKPF, un documento parcheggiato è identificato dal valore «V» nel campo dello stato del documento (BSTAT). La data dell’evento corrisponde alla data di creazione (CPUDT). Acquisizione Filtri i documenti per cui BKPF-BSTAT = 'V' al momento della creazione. Tipo di evento explicit | |||
| Registrazione contabile rifiutata | Un revisore o un approvatore rifiuta la registrazione contabile, impedendone la registrazione. In genere, il documento viene restituito a chi lo ha creato affinché lo corregga, avviando un ciclo di rilavorazione. | ||
| Perché è importante Monitorare i rifiuti è fondamentale per comprendere la qualità del processo e individuare gli errori più comuni. Un tasso di rifiuto elevato segnala problemi di accuratezza dei dati, comprensione delle procedure o completezza della documentazione di supporto. Dove reperirli L’evento viene dedotto da una modifica dello stato nel log del flusso di lavoro o in un campo di stato personalizzato del documento di registrazione contabile. I log delle modifiche al documento (CDHDR/CDPOS) relativi al campo di stato pertinente possono fornire la data e l’ora dell’evento. Acquisizione Individui la modifica del campo di stato in «Rifiutato» tramite i documenti delle modifiche (CDHDR/CDPOS) o i log del flusso di lavoro. Tipo di evento inferred | |||
| Registrazione manuale individuata | La registrazione contabile è stata registrata utilizzando un codice transazione manuale, anziché un’interfaccia automatizzata o un’elaborazione in batch. Non si tratta di un evento temporale, ma di una classificazione dell’attività di registrazione. | ||
| Perché è importante Individuare le registrazioni manuali è fondamentale per le iniziative di automazione. Un’elevata percentuale di registrazioni manuali segnala opportunità per semplificare i processi integrando i sottosistemi o utilizzando programmi di registrazione automatizzati. Dove reperirli La classificazione si basa sull’analisi del campo del codice transazione (TCODE) nella tabella di testata del documento (BKPF). Per classificare la registrazione si utilizza un elenco di codici transazione manuali noti, ad esempio FB01, F-02 e FB50. Acquisizione Classifichi l’evento confrontando BKPF-TCODE con un elenco predefinito di codici transazione manuali al momento della registrazione. Tipo di evento calculated | |||
Guide all’estrazione
Passaggi
- Prerequisiti e accesso: Si assicuri di disporre di un utente con le autorizzazioni necessarie per interrogare il database sottostante di SAP S/4HANA o eseguire report ABAP. È necessario avere accesso in lettura alle viste CDS I_JournalEntry e I_JournalEntryItem e alle tabelle CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ e SWWLOGHIST. In genere, l’accesso viene concesso tramite un client di database come SAP HANA Studio o DBeaver, oppure utilizzando gli ABAP Development Tools (ADT) di SAP per Eclipse.
- Individui le configurazioni specifiche del sistema: Prima di eseguire la query, individui i codici task specifici utilizzati nel flusso di lavoro di approvazione delle registrazioni contabili. Si rivolga all’amministratore dei flussi di lavoro SAP per individuare gli ID task (ad esempio, TS12345678) associati agli eventi di invio, rifiuto e approvazione. Questi valori sono necessari per i segnaposto nella query finale.
- Prepari la query SQL: Copi la query SQL completa fornita nella sezione
querynel client SQL o nello strumento di sviluppo scelto. - Imposti i parametri della query: Individui i segnaposto nella query e li sostituisca con i valori specifici. Imposti i parametri
[YourCompanyCode],[StartDate]e[EndDate]. Sostituisca inoltre i segnaposto degli ID task del flusso di lavoro ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) con i valori individuati nel passaggio precedente. - Esegua la query di estrazione: Esegua la query SQL modificata sul database SAP S/4HANA. A seconda dell’intervallo di date e del volume dei dati, l’esecuzione potrebbe richiedere molto tempo. Si consiglia di eseguirla nelle fasce orarie di minore attività.
- Riveda i risultati iniziali: Al termine della query, controlli le prime righe dell’output per verificare che tutte le colonne, come JournalEntryId, ActivityName ed EventTime, contengano i valori previsti. Il risultato dovrebbe includere una riga per ogni evento aziendale distinto nel ciclo di vita della registrazione contabile.
- Esporti i dati in CSV: Esporti l’intero risultato dallo strumento SQL in un unico file CSV. Si assicuri che il file utilizzi la codifica UTF-8 per evitare problemi con i caratteri speciali.
- Prepari il caricamento: Prima di caricare i dati in uno strumento di Process Mining, verifichi che il file CSV contenga le intestazioni richieste. I dati sono già strutturati come Event Log, quindi non dovrebbe essere necessaria alcuna ulteriore trasformazione o riorganizzazione.
Configurazione
- Viste Core Data Services (CDS): L’estrazione utilizza principalmente
I_JournalEntryper i dati di intestazione eI_JournalEntryItemper i dettagli delle righe e degli importi. Queste viste offrono un’interfaccia semplificata e semanticamente ricca per il libro mastro universale (ACDOCA). - Tabelle di supporto: Per ottenere una visione completa del processo, la query unisce anche diverse tabelle SAP standard:
CDHDReCDPOSper monitorare le modifiche ai documenti.SRGBRELeSOODper individuare il collegamento degli allegati tramite Generic Object Services (GOS).SWW_WI2OBJeSWWLOGHISTper estrarre gli eventi principali del flusso di lavoro di approvazione.
- Filtro per intervallo di date: Per gestire le prestazioni, è fondamentale filtrare i dati in base a un intervallo di date specifico. Utilizzi il campo
I_JournalEntry.CreationDateTimenella clausolaWHERE. Per l’analisi iniziale si consiglia un intervallo da 3 a 6 mesi. - Filtro organizzativo: Filtri sempre per
CompanyCodeper limitare l’estrazione alle società pertinenti. In un sistema di grandi dimensioni, interrogare contemporaneamente tutti i codici società può comportare tempi di esecuzione molto lunghi. - ID task del flusso di lavoro: La query contiene segnaposto per gli ID task del flusso di lavoro (ad esempio,
[Workflow Approved Task ID]). Questi ID sono specifici di ogni installazione SAP e devono essere configurati correttamente per estrarre le attività del flusso di lavoro. In loro assenza, non verranno acquisiti gli eventi di invio, approvazione o rifiuto. - Prerequisiti: L’utente che esegue la query deve disporre di ampie autorizzazioni di lettura per le tabelle finanziarie, di sistema e dei flussi di lavoro. Queste autorizzazioni non sono standard e devono essere assegnate in modo specifico.
Query di esempio sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Passaggi
- Verifichi che l’accesso SQL diretto al database SAP HANA sia autorizzato e che l’utente incaricato dell’estrazione disponga delle autorizzazioni di lettura per BKPF e ACDOCA, oltre che per le eventuali fonti configurate relative a flussi di lavoro, allegati, cronologia delle modifiche, compensazioni o storni richieste dal sistema. In genere, l’accesso diretto al database avviene tramite SAP HANA Database Explorer, SAP HANA Studio o un client SQL approvato. Non esegua query di estrazione in una transazione applicativa SAP, a meno che il sistema non supporti esplicitamente tale modalità di accesso.
- Verifichi lo schema fisico di BKPF e ACDOCA, inclusi i campi relativi al client, al codice società, all’anno fiscale, al numero e al tipo di documento, alla data di registrazione, alla data e all’ora di creazione, all’utente, all’importo in valuta locale e agli eventuali storni o compensazioni. Le installazioni di SAP S/4HANA possono differire per schema e disponibilità dei campi; sostituisca quindi i segnaposto tra parentesi quadre nella query con campi verificati nel sistema.
- Individui le fonti autorevoli degli eventi relativi ai flussi di lavoro e agli allegati. BKPF e ACDOCA forniscono dati sui documenti contabili e sulle righe, ma da sole non espongono in modo affidabile tutti gli eventi di parcheggio, invio, rifiuto, correzione, approvazione o allegato. Sostituisca i segnaposto tra parentesi quadre relativi alle fonti di flussi di lavoro e allegati con viste o tabelle approvate per l’implementazione. Se una fonte non è disponibile, non inventi eventi: configuri la fonte corrispondente oppure escluda l’attività previa approvazione documentata.
- Imposti i parametri di estrazione per l’intervallo di date richiesto, i codici società, i tipi di documento e il client. Per la convalida iniziale si consiglia un intervallo da tre a sei mesi. In base all’ambito concordato del processo, utilizzi l’intervallo dei timestamp degli eventi per gli eventi operativi e l’intervallo delle date di registrazione per gli eventi contabili.
- Esegua la query SQL completa nel client SQL HANA approvato. La query crea una riga di evento per ogni attività estratta esplicitamente. Utilizza BKPF e ACDOCA per gli eventi contabili e le viste configurate per gli eventi relativi a flussi di lavoro, allegati, modifiche, compensazioni e storni. Non deduce le attività dalla sola esistenza di un documento.
- Riveda lo schema dell’output. JournalEntryId è l’identificativo del caso, ActivityName è l’etichetta dell’attività ed EventTime è il timestamp dell’evento; gli attributi aziendali consigliati vengono restituiti quando disponibili. Verifichi che EventTime sia un timestamp e che tutte le righe abbiano un JournalEntryId e un ActivityName non vuoti.
- Riconcili la popolazione contabile confrontando i valori distinti di JournalEntryId con la popolazione BKPF prevista per il client, i codici società, gli anni fiscali e l’intervallo di date selezionati. Riconcili separatamente le popolazioni relative ai flussi di lavoro e agli allegati, poiché le regole di conservazione e dei timestamp potrebbero differire da quelle dei dati contabili.
- Convalidi l’ordinamento degli eventi e la gestione dei duplicati. Le righe multiple in ACDOCA non devono generare eventi contabili duplicati, a meno che il modello di processo non richieda intenzionalmente eventi a livello di riga. Utilizzi la logica di aggregazione della query per produrre un evento contabile per registrazione e tipo di evento, mantenendo gli identificativi degli eventi della fonte configurata, quando disponibili.
- Esporti il risultato in un file CSV UTF-8 o in un altro formato tabellare supportato da ProcessMind. Mantenga esattamente i nomi delle colonne JournalEntryId, ActivityName ed EventTime. Ordini il file per JournalEntryId ed EventTime e conservi gli attributi aggiuntivi come colonne. Carichi il file in ProcessMind e configuri JournalEntryId come identificativo del caso, ActivityName come attività ed EventTime come timestamp dell’evento.
Configurazione
- Intervallo di date: Inizi con un periodo da tre a sei mesi. Per i test delle prestazioni utilizzi un intervallo più breve e lo estenda solo dopo aver convalidato il numero di righe e la copertura degli eventi.
- Ambito di client e società: Imposti [Client parameter] e limiti CompanyCode alle società richieste. In un sistema con più client, non ometta il filtro sul client.
- Ambito contabile: Configuri [Document type filter] e, se opportuno, i filtri per anno fiscale e data di registrazione. Includa i documenti registrati e non registrati solo se la fonte selezionata li rappresenta in modo affidabile.
- Ambito dei flussi di lavoro: Configuri [Workflow event source] e le relative mappature dei tipi di evento per le attività di invio, rifiuto, correzione e approvazione. Verifichi se i timestamp indicano la creazione, l’esecuzione o il completamento dell’azione nel flusso di lavoro.
- Ambito degli allegati: Configuri [Attachment event source] e il campo di relazione che collega un allegato alla registrazione contabile. Verifichi se la fonte registra la creazione, la sostituzione o l’eliminazione degli allegati.
- Ambito delle modifiche: Configuri [Change history source] per le modifiche successive alla registrazione. Verifichi che la fonte identifichi la registrazione contabile e fornisca un timestamp affidabile della modifica.
- Ambito delle compensazioni: Configuri [Clearing source] e la relazione tra il documento contabile compensato e il documento di compensazione. Decida se assegnare l’evento alla registrazione contabile originale, al documento di compensazione o a entrambi.
- Ambito degli storni: Configuri [Reversal source] e la relazione tra il documento originale e quello di storno. Quando la relazione è disponibile, la query assegna l’attività di storno al JournalEntryId originale.
- Classificazione delle registrazioni manuali: Configuri [Manual posting source] o un campo verificato relativo all’origine della registrazione. Manual Posting Identified è un evento di classificazione e deve utilizzare in modo coerente il timestamp di registrazione o un altro timestamp approvato.
- Importo in valuta: ACDOCA è strutturata a livello di riga. La query aggrega gli importi in valuta locale per registrazione contabile. Verifichi la convenzione dei segni e se includere le righe statistiche, specifiche del libro mastro o dei libri mastro di estensione.
- Prestazioni: Selezioni solo le colonne necessarie, applichi i filtri nelle prime fasi, eviti scansioni senza restrizioni di ACDOCA ed esegua la query durante una finestra di elaborazione approvata. Ove supportato, utilizzi il partizionamento tramite i filtri per client, anno fiscale, codice società e data di registrazione.
- Gestione dei duplicati: Utilizzi gli identificativi degli eventi della fonte, quando disponibili. Se una fonte può contenere record tecnici ripetuti, applichi la regola di deduplicazione documentata senza accorpare azioni distinte del flusso di lavoro.
- Prerequisiti: Autorizzazioni necessarie per il database, connettività SAP HANA approvata, accesso alle fonti configurate per flussi di lavoro e allegati, configurazione appropriata di SAP Financial Accounting e dei flussi di lavoro e formato di esportazione supportato da ProcessMind.
Query di esempio sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Passaggi
- Crei il programma ABAP: Acceda all’editor ABAP tramite il codice transazione
SE38. Inserisca un nome per il nuovo programma, ad esempioZ_PM_JE_EXTRACT, e selezioni 'Create'. Assegni un titolo appropriato, imposti 'Type' su 'Executable Program' e salvi il programma come oggetto locale o all’interno di un package. - Definisca la schermata di selezione: Nel programma, definisca i parametri e le opzioni di selezione che consentiranno agli utenti di filtrare i dati. Includa un intervallo di date per la data di creazione della registrazione contabile (
P_CPUDT_FR,P_CPUDT_TO), un’opzione di selezione per il codice società (SO_BUKRS) e il percorso del file di output sul server applicativo (P_FPATH). - Dichiari le strutture dati: Definisca una struttura di tabella interna conforme al formato richiesto per l’Event Log, che conterrà l’output finale. Dichiari inoltre le tabelle interne e le aree di lavoro per le tabelle SAP da cui verranno selezionati i dati, come BKPF, ACDOCA, CDHDR, CDPOS e le varie tabelle dei flussi di lavoro.
- Implementi la logica di selezione dei dati: Scriva la logica ABAP principale per recuperare i dati relativi a ciascuna delle 12 attività richieste. Crei routine separate (FORM) per ogni attività, in modo da mantenere il codice organizzato. Ad esempio, crei una FORM per
get_created_events, una perget_parked_eventse una perget_workflow_events. - Selezioni gli eventi 'Created' e 'Posted': Legga i dati dalla tabella BKPF in base ai criteri impostati nella schermata di selezione. Una registrazione in BKPF indica la creazione. Un documento con stato
BSTAT = ' 'è considerato registrato. Utilizzi il timestamp di creazione (CPUDT,CPUTM) come orario dell’evento. - Selezioni gli eventi 'Parked': Legga i dati dalla tabella VBKPF, che contiene le intestazioni dei documenti parcheggiati. Il timestamp di creazione in questa tabella rappresenta l’evento di parcheggio.
- Selezioni gli eventi del flusso di lavoro ('Submitted', 'Approved', 'Rejected'): Interroghi tabelle del flusso di lavoro come SWW_WI2OBJ, per collegare un oggetto di registrazione contabile a un’istanza del flusso di lavoro, e SWWLOGHIST o SWWIHEAD, per ottenere i dettagli e gli orari dei singoli passaggi. Dovrà individuare gli ID task specifici utilizzati nel sistema per l’invio, l’approvazione e il rifiuto.
- Selezioni gli eventi 'Change' e 'Correction': Interroghi le tabelle dei documenti di modifica CDHDR (intestazione) e CDPOS (riga) per
OBJECTCLAS = 'BELEG'. Per 'Changed After Posting', filtri le modifiche con timestamp successivo alla data di registrazione del documento. Per 'Corrected', filtri le modifiche ai documenti parcheggiati o rifiutati. - Selezioni gli eventi 'Reversal' e 'Cleared': Individui gli storni cercando i documenti in cui il campo
STBLG(numero del documento stornato) di BKPF è valorizzato. L’orario dell’evento di storno corrisponde all’ora di creazione del documento di storno. Individui gli eventi di compensazione selezionando la data di compensazione più recente (AUGDT) in ACDOCA per le righe di una determinata registrazione contabile. - Combini e ordini i dati: Man mano che seleziona i dati di ciascuna attività, aggiunga i risultati alla tabella interna principale finale. Una volta completate tutte le selezioni, ordini la tabella per
JournalEntryIdedEventTime, così da ottenere l’ordine cronologico di ogni caso. - Generi il file di output: Utilizzi le istruzioni
OPEN DATASET,LOOP AT... TRANSFEReCLOSE DATASETper scrivere il contenuto della tabella interna finale ordinata nel percorso specificato sul server applicativo SAP. Il file deve essere in formato CSV e includere una riga di intestazione. - Pianifichi l’esecuzione: Per le estrazioni periodiche, utilizzi il codice transazione
SM36per creare un job in background che esegua il programmaZ_PM_JE_EXTRACTsecondo una pianificazione definita, ad esempio settimanale o mensile. In questo modo, l’esportazione dei dati viene eseguita automaticamente.
Configurazione
- Intervallo di date: La schermata di selezione deve prevedere un intervallo di date obbligatorio per la data di creazione della registrazione contabile (
CPUDT). Per garantire buone prestazioni, si consiglia di estrarre i dati in blocchi gestibili, ad esempio da 3 a 6 mesi alla volta. - Codice società (
BUKRS): È un filtro fondamentale per limitare l’estrazione alle società pertinenti all’analisi di Process Mining. Si sconsiglia di estrarre contemporaneamente i dati di tutti i codici società. - Tipo di documento (
BLART): Può aggiungere questo filtro facoltativo per concentrarsi su tipi specifici di registrazioni contabili, ad esempio 'SA' per le registrazioni in conto Co.Ge. o 'KR' per le fatture fornitori. In questo modo è possibile ridurre il volume dei dati e aumentare la pertinenza del dataset. - Percorso del file: Il programma richiede un percorso logico sul server applicativo SAP in cui scrivere il file di output. Verifichi che il percorso sia valido e che l’utente di sistema SAP disponga delle autorizzazioni di scrittura necessarie per la directory. Utilizzi la transazione
AL11per gestire e visualizzare le directory del server. - ID task del flusso di lavoro: La logica di estrazione degli eventi del flusso di lavoro (Submitted, Approved, Rejected) deve essere configurata con gli ID task specifici utilizzati nel flusso di lavoro di approvazione delle registrazioni contabili dell’organizzazione. Spesso si tratta di ID personalizzati, che devono essere individuati con l’aiuto di un consulente o sviluppatore specializzato nei flussi di lavoro.
- Prerequisiti: L’utente o l’account di sistema che esegue il programma deve disporre delle autorizzazioni di sviluppo per creare ed eseguire programmi ABAP (
S_DEVELOP) e di ampio accesso in lettura alle tabelle finanziarie (BKPF, ACDOCA), alle tabelle dei log delle modifiche (CDHDR, CDPOS) e alle tabelle dei flussi di lavoro (SWW*).
Query di esempio abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM. È pronto a iniziare?
Utilizzi questo template per preparare i dati con sicurezza e ottenere informazioni preziose sul processo Record to Report - Registrazione contabile. Inizi oggi il percorso verso l’eccellenza dei processi.
Ottimizzi le registrazioni contabili Record to Report per la massima efficienza
Trasformi il processo e riduca del 30% il tempo di ciclo delle registrazioni contabili Record to Report.
Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.