Il Suo Template dei dati Record to Report per le registrazioni contabili
Il Suo Template dei dati Record to Report per le registrazioni contabili
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni pratiche per l’estrazione
Record to Report - Attributi delle registrazioni contabili
| Nome | Descrizione | ||
|---|---|---|---|
| Attività ActivityName | Il nome dell’attività aziendale che si è verificata in un determinato punto del processo delle registrazioni contabili. | ||
| 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 eseguita». Queste attività derivano in genere dai log delle modifiche, dagli aggiornamenti di stato o dai codici transazione registrati nel sistema. L’analisi delle attività consente di visualizzare il flusso del processo, identificare i percorsi più comuni e individuare le deviazioni dalla procedura standard. È fondamentale per calcolare metriche come la frequenza delle attività, i tempi di attesa tra i passaggi e i tassi di conformità. Perché è importante Definisce i passaggi del processo, consentendo di visualizzare le mappe di processo e analizzare i modelli del Workflow. Dove reperirlo Derivata da diverse fonti, inclusi i campi di stato nelle tabelle di testata e delle posizioni, come BKPF-BSTAT, i log dei documenti di modifica (CDHDR/CDPOS) e i log del Workflow. Esempi Registrazione contabile creataRegistrazione contabile parcheggiataRegistrazione contabile inviata per la revisioneRegistrazione contabile approvataRegistrazione contabile eseguita | |||
| ID della registrazione contabile JournalEntryId | L’identificatore univoco di una registrazione contabile, che funge da identificativo principale del caso per il processo. | ||
| Descrizione L’ID della registrazione contabile è un numero univoco assegnato a ogni documento contabile al momento della creazione in SAP S/4HANA. Questo identificatore è essenziale per monitorare l’intero ciclo di vita di una registrazione contabile, dalla creazione o dal parcheggio iniziale, attraverso i Workflow di approvazione, fino alla registrazione finale e a un eventuale storno o compensazione. Nell’analisi di Process Mining, questo ID viene utilizzato per collegare tutte le attività correlate in un unico caso. Raggruppando gli eventi sotto un ID comune della registrazione contabile, gli analisti possono ricostruire il flusso end-to-end del processo, misurare i tempi di ciclo e identificare variazioni o colli di bottiglia per ogni specifica transazione finanziaria. È l’Attributo fondamentale per costruire l’intera vista del processo. Perché è importante Questo identificatore collega tutti i passaggi correlati del processo, rendendo possibile analizzare il percorso end-to-end di ogni registrazione contabile. Dove reperirlo Si tratta di una chiave composta, generalmente formata concatenando il codice società (BKPF-BUKRS), il numero documento (BKPF-BELNR) e l’esercizio fiscale (BKPF-GJAHR). Esempi 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Ora dell’evento EventTime | Il timestamp che indica quando si è verificata una specifica attività per la registrazione contabile. | ||
| Descrizione L’ora dell’evento è la data e l’ora precise in cui un’attività aziendale è stata eseguita e registrata nel sistema. Ogni attività di un caso ha il proprio timestamp, creando 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, le durate tra le attività e i tempi di attesa, oltre che per comprendere la distribuzione temporale del lavoro. Timestamp accurati sono essenziali per costruire un modello di processo affidabile e calcolare indicatori chiave di prestazione come il tempo del ciclo di approvazione. Perché è importante Fornisce l’ordine cronologico degli eventi, essenziale per calcolare tutte le metriche basate sulla durata e comprendere la sequenza temporale del processo. Dove reperirlo Proveniente dai log dei documenti di modifica (CDHDR-UDATE, CDHDR-UTIME), dai log del Workflow o dai timestamp di creazione e inserimento in tabelle come BKPF (CPUDT, CPUTM). Esempi 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Data di registrazione PostingDate | La data in cui la registrazione contabile viene registrata nella contabilità generale, determinando il periodo finanziario di riferimento. | ||
| Descrizione La data di registrazione determina il periodo fiscale in cui la transazione comparirà nei bilanci. È una data fondamentale per la contabilità e può differire dalla data di creazione del documento o da quella in cui il documento è stato inserito nel sistema. Nel Process Mining, la data di registrazione viene utilizzata per analisi di coorte basate sul tempo, ad esempio per confrontare i processi di chiusura di fine mese o analizzare l’andamento delle prestazioni in diversi periodi finanziari. Viene inoltre utilizzata per misurare i ritardi tra la creazione della registrazione e la sua effettiva contabilizzazione. Perché è importante È fondamentale per il contesto finanziario e consente di analizzare le prestazioni del processo in specifici periodi contabili, come la chiusura mensile o annuale. Dove reperirlo Tabella SAP S/4HANA BKPF, campo BUDAT (data di registrazione nel documento). Esempi 2023-10-312023-11-012024-02-29 | |||
| Importo in valuta locale AmountInLocalCurrency | Il valore totale della registrazione contabile espresso nella valuta locale del codice società. | ||
| Descrizione Questo attributo rappresenta l’entità finanziaria della registrazione contabile. Generalmente 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. Ad esempio, le registrazioni di importo elevato possono seguire un processo di approvazione più rigoroso rispetto a quelle di importo ridotto. In questo modo è possibile dare priorità agli interventi di miglioramento del processo sulle transazioni che comportano il rischio finanziario maggiore. Perché è importante Fornisce il valore finanziario della registrazione, consentendo di analizzare come cambia il comportamento del processo in funzione dell’importo in gioco. Dove reperirlo 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 | |||
| Società CompanyCode | L’identificativo univoco della società o dell’entità giuridica per la quale viene registrata la registrazione 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 registrazione contabile viene assegnata a uno specifico codice società. Questo attributo è essenziale per segmentare e confrontare le prestazioni del processo tra diverse aree dell’organizzazione. Gli analisti possono utilizzarlo per filtrare la vista del processo relativa a una specifica entità giuridica, confrontare i tassi di rifiuto tra codici società oppure individuare variazioni del processo specifiche di una regione. Perché è importante Consente di filtrare e confrontare il processo di registrazione contabile tra diverse entità giuridiche o unità aziendali dell’organizzazione. Dove reperirlo Tabella SAP S/4HANA BKPF, campo BUKRS (codice società). Esempi 10001710US01 | |||
| Tipo di registrazione contabile JournalEntryType | Classifica la registrazione contabile in base alla sua finalità aziendale, ad esempio registrazione di un cespite, fattura fornitore o registrazione nella contabilità generale. | ||
| Descrizione Il tipo di registrazione contabile, denominato tipo documento nella terminologia SAP, è una chiave che categorizza i documenti contabili. Controlla 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 contabile è fondamentale per comprendere i comportamenti specifici del contesto. Ad esempio, il processo di approvazione di un semplice rateo, di tipo SA, può essere molto più semplice rispetto a quello di un’acquisizione complessa di un cespite, di tipo AA. Questa dimensione è fondamentale per la Dashboard «Conformità per tipo di registrazione». Perché è importante Categorizza le registrazioni in base al contesto aziendale, consentendo di analizzare le variazioni e le prestazioni del processo per diversi tipi di transazioni finanziarie. Dove reperirlo Tabella SAP S/4HANA BKPF, campo BLART (tipo documento). Esempi SAKRAA | |||
| Utente che ha creato la registrazione CreatedByUser | L’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 oppure dell’ID di un sistema per le registrazioni automatizzate. Analizzare il processo in base all’autore consente di individuare schemi associati a utenti o team specifici. Può evidenziare esigenze formative se determinati utenti presentano tassi di rifiuto più elevati oppure mettere in luce le persone con le migliori prestazioni. È essenziale per la Dashboard «Attività e produttività degli utenti». Perché è importante Attribuisce le attività del processo a utenti specifici, consentendo di analizzare le prestazioni, bilanciare i carichi di lavoro e individuare opportunità di formazione. Dove reperirlo Tabella SAP S/4HANA BKPF, campo USNAM (nome utente). Esempi ABROWNCJONESBATCH_USER | |||
| Anno fiscale FiscalYear | L’anno fiscale a cui appartiene la registrazione contabile. | ||
| Descrizione L’anno fiscale fa parte della chiave univoca di una registrazione contabile, insieme al codice società e al numero del documento. Rappresenta l’anno finanziario in cui il documento è rilevante. Nell’analisi, l’anno fiscale viene utilizzato per le analisi delle tendenze a lungo termine e per garantire l’univocità dell’identificativo del caso. Il confronto delle metriche di processo tra anni fiscali diversi può evidenziare miglioramenti o peggioramenti delle prestazioni nel tempo. Perché è importante Fornisce un elemento fondamentale per identificare univocamente i documenti e consente di analizzare le prestazioni del processo anno su anno. Dove reperirlo Tabella SAP S/4HANA BKPF, campo GJAHR (anno fiscale). Esempi 202320242022 | |||
| Codice transazione TransactionCode | Il codice transazione SAP utilizzato per creare o modificare la registrazione contabile. | ||
| Descrizione Il codice transazione, o T-Code, è una scorciatoia che identifica una specifica funzione o un programma in SAP. Per le registrazioni contabili, T-Code diversi possono indicare le modalità di creazione della registrazione, ad esempio FB01 per una registrazione manuale nella contabilità generale, FV50 per il parcheggio oppure un codice automatizzato per le registrazioni generate dal sistema. Questo attributo è un indicatore efficace per stabilire 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, un’informazione fondamentale per analizzare l’automazione e comprendere le variazioni del processo. Dove reperirlo Tabella SAP S/4HANA BKPF, campo TCODE (codice transazione). Esempi FB01FV50F-02 | |||
| È una registrazione manuale IsManualPosting | Un flag booleano che indica se la registrazione contabile è stata registrata manualmente da un utente. | ||
| Descrizione Questo attributo identifica le registrazioni contabili inserite con l’intervento manuale di un utente, anziché registrate automaticamente da un job di sistema o da un’interfaccia. Generalmente viene derivato dal codice transazione utilizzato per registrare il documento. Il flag viene utilizzato per 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 inserite manualmente, 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 elemento fondamentale per misurare il livello di automazione e individuare nuove opportunità di automazione. Dove reperirlo Si tratta di un attributo calcolato derivato da TransactionCode. Un elenco predefinito di codici transazione manuali, ad esempio «FB01» e «F-02», viene utilizzato per impostare il flag su «true». Esempi truefalse | |||
| È una rilavorazione IsRework | Un flag booleano che indica se la registrazione contabile è stata sottoposta a rilavorazione, ad esempio se è stata corretta dopo un rifiuto. | ||
| Descrizione Questo attributo calcolato segnala le registrazioni contabili che si sono discostate dal percorso ideale, o «happy path», del processo. Generalmente viene impostato su true se nel caso si verifica un’attività come «Registrazione contabile rifiutata» o «Registrazione contabile corretta». Il flag semplifica l’analisi dell’efficienza del processo. Consente di calcolare rapidamente il KPI del tasso di rilavorazione e di confrontare direttamente tempi di ciclo e costi tra i casi con e senza rilavorazione. Individuare i fattori che determinano le rilavorazioni è uno degli obiettivi principali di molte iniziative di miglioramento dei processi. Perché è importante Segnala i casi che hanno richiesto correzioni o cicli aggiuntivi, consentendo di quantificare facilmente e analizzare le cause principali delle inefficienze del processo. Dove reperirlo Si tratta di un attributo calcolato derivato dalla sequenza delle attività in un caso. Viene impostato su «true» se è presente un’attività come «Registrazione contabile rifiutata». Esempi truefalse | |||
| Motivo dello storno ReversalReason | Un codice che indica il motivo per cui una registrazione contabile registrata è stata stornata. | ||
| Descrizione Quando una registrazione contabile registrata contiene un errore, non può essere eliminata, ma deve essere stornata mediante un nuovo documento. Il codice del motivo dello storno spiega perché è stata eseguita questa operazione, ad esempio a causa di una data di registrazione o di un importo errato. L’analisi dei motivi di storno aiuta a individuare le cause principali degli errori nel processo Record to Report. Una frequenza elevata di un determinato motivo può indicare problemi sistemici, come formazione insufficiente o carenze nei controlli, che devono essere affrontati per migliorare la qualità al primo tentativo. Perché è importante Aiuta a diagnosticare la causa principale degli errori che portano agli storni, fornendo informazioni utili per ridurre le rilavorazioni e migliorare la qualità del processo. Dove reperirlo Tabella SAP S/4HANA BKPF, campo STGRD (motivo dello storno). Esempi 010205 | |||
| Ora di fine EndTime | Il timestamp che indica quando l’attività è stata completata. | ||
| Descrizione L’ora di fine indica il completamento di un’attività. In molti Event Log, l’ora di inizio e l’ora di fine di un’attività coincidono, poiché rappresentano un evento istantaneo. Tuttavia, per le attività con una durata misurabile, come la revisione attiva di un documento da parte di un utente, questo attributo può registrare tale durata. La disponibilità di un’ora di fine distinta consente di calcolare con maggiore precisione i tempi di elaborazione delle attività, separandoli dai tempi di attesa. Permette di distinguere il tempo durante il quale un’attività è stata effettivamente lavorata dal tempo in cui è rimasta inattiva in una coda. Perché è importante Consente di calcolare con precisione i tempi di elaborazione delle attività, separando il tempo di lavoro effettivo dal tempo di attesa. Dove reperirlo Generalmente coincide con StartTime per gli eventi atomici. Per le attività con durata, può essere ricavata dai log del Workflow oppure calcolata sulla base degli 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 dal quale sono stati estratti i dati delle registrazioni contabili. | ||
| Descrizione Questo attributo specifica il sistema di riferimento da cui hanno origine i dati della registrazione contabile. Per le aziende che utilizzano più istanze ERP o una combinazione di sistemi legacy e moderni, consente di distinguere le diverse origini dei dati. Nell’analisi può essere utilizzato per confrontare le prestazioni del processo tra sistemi diversi oppure per filtrare i dati relativi a una fonte specifica. È importante per la governance dei dati e per garantire che il contesto dei dati sia adeguatamente compreso. Perché è importante Fornisce il contesto sull’origine dei dati, un elemento fondamentale negli ambienti multi-sistema per analizzare e confrontare correttamente i processi. Dove reperirlo Si tratta generalmente di un valore statico aggiunto durante l’estrazione dei dati, che identifica l’istanza SAP S/4HANA specifica, ad esempio il SID o il nome del sistema logico. Esempi S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Stato del documento DocumentStatus | Lo stato di elaborazione corrente della registrazione contabile, ad esempio parcheggiata, registrata o compensata. | ||
| Descrizione Lo stato del documento indica la posizione della registrazione contabile nel suo ciclo di vita. Ad esempio, un documento «parcheggiato» è stato salvato ma non è ancora stato registrato nella contabilità generale, mentre un documento «registrato» è definitivo. L’analisi dello stato aiuta a comprendere il flusso di lavoro e a individuare i colli di bottiglia. Un volume elevato di documenti che rimangono a lungo nello stato «parcheggiato» o «in attesa di approvazione» può segnalare inefficienze nel processo. Lo stato è inoltre una fonte fondamentale per derivare le attività del processo. Perché è importante Fornisce una fotografia della posizione della registrazione contabile nel suo ciclo di vita e aiuta a individuare code e colli di bottiglia. Dove reperirlo Tabella SAP S/4HANA BKPF, campo BSTAT (stato del documento). Esempi VAB | |||
| Tempo del ciclo di approvazione ApprovalCycleTime | Il tempo trascorso dall’invio di una registrazione contabile per l’approvazione fino alla sua approvazione o al suo rifiuto. | ||
| Descrizione Questa metrica calcolata si concentra specificamente sulla durata della fase di approvazione. Misura 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 all’interno del Workflow di approvazione. Tempi di ciclo elevati possono ritardare significativamente l’intero processo. Analizzare questa metrica per approvatore, codice società o tipo di registrazione contabile può far emergere aree specifiche di miglioramento. Perché è importante Isola la durata della fase di approvazione, aiutando a individuare e risolvere i colli di bottiglia nel Workflow di revisione e approvazione. Dove reperirlo Calcolato determinando 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 | Timestamp che indica l’ultima volta in cui i dati relativi a questo record sono stati aggiornati 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. Fornisce trasparenza sul livello di aggiornamento dei dati analizzati. Conoscere l’ora dell’ultimo aggiornamento è importante per comprendere quanto siano attuali i risultati dell’analisi del processo. Aiuta a interpretare correttamente Dashboard e KPI, indicando se si stanno esaminando dati quasi in tempo reale oppure una fotografia relativa a un periodo precedente. Perché è importante Indica il livello di aggiornamento dei dati, consentendo agli utenti di sapere quanto siano attuali i risultati dell’analisi del processo. Dove reperirlo Si tratta di un attributo di metadati, generalmente generato e registrato in ogni record durante la pipeline di acquisizione dei dati. Esempi 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Utente approvatore ApproverUser | L’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. In un Workflow di approvazione multilivello, una singola registrazione contabile può avere diversi approvatori. Queste informazioni sono essenziali per analizzare nel dettaglio il processo di approvazione. Consentono di misurare il carico di lavoro dei diversi approvatori, calcolare i singoli tempi di approvazione e individuare i colli di bottiglia nella catena di approvazione. Supportano direttamente la Dashboard «Attività e produttività degli utenti». Perché è importante Identifica la persona responsabile dell’approvazione, consentendo di analizzare i carichi di lavoro, le prestazioni e i colli di bottiglia del processo di approvazione. Dove reperirlo Ricavato dai log del Workflow, ad esempio SWW_WI2OBJ e SWWLOG, oppure dalle tabelle dei documenti di modifica, CDHDR/CDPOS, monitorando l’utente che ha eseguito il passaggio di approvazione. Esempi DMILLERFWHITEKCHEN | |||
Record to Report - Attività delle registrazioni contabili
| Attività | Descrizione | ||
|---|---|---|---|
| Processo di storno della registrazione contabile completato | Una registrazione contabile precedentemente eseguita viene stornata creando un nuovo documento con registrazioni inverse. Questa azione serve a correggere errori nei documenti registrati ed è una transazione esplicita e verificabile. | ||
| Perché è importante Gli storni indicano che è stato commesso un errore in un documento registrato. Un tasso elevato di storni suggerisce problemi sottostanti nel processo di approvazione o nella qualità dell’inserimento dei dati; monitorarli aiuta a migliorare l’accuratezza al primo inserimento. Dove reperirlo 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 rappresenta il momento dell’evento. Acquisizione Identifichi i documenti per i quali BKPF-STBLG è valorizzato. Il timestamp dell’evento è la data di registrazione del documento di storno. Tipo di evento explicit | |||
| Registrazione contabile approvata | La registrazione contabile riceve l’approvazione finale da parte di un responsabile autorizzato, che ne conferma validità e accuratezza. Questa attività rappresenta l’ultimo controllo prima che il documento possa essere registrato nel libro mastro. | ||
| Perché è importante Si tratta di una tappa fondamentale che conclude il ciclo di approvazione. Il tempo necessario per raggiungerla costituisce una componente significativa della durata complessiva del processo e un indicatore importante dell’efficienza degli approvatori. Dove reperirlo Questo evento viene dedotto da un log del Workflow che mostra il passaggio di approvazione finale o una modifica dello stato del documento. L’ID utente dell’approvatore e il timestamp possono essere ricavati dai dati del Workflow o dai log delle modifiche. Acquisizione Identifichi il timestamp del passaggio di approvazione finale nei log del Workflow oppure la modifica dello stato in «Approvato» nei documenti di modifica. Tipo di evento inferred | |||
| Registrazione contabile compensata | Una posizione aperta all’interno di una registrazione contabile viene compensata da un’altra registrazione, ad esempio quando un pagamento compensa una fattura. Questa attività indica la riconciliazione di specifiche posizioni e, di fatto, la loro chiusura. | ||
| Perché è importante Questa attività rappresenta la fase finale di riconciliazione per molte registrazioni contabili, in particolare quelle che coinvolgono conti transitori o gestiti per partite aperte. Analizzare il tempo che intercorre tra registrazione e compensazione aiuta a misurare l’efficienza della riconciliazione. Dove reperirlo L’evento viene dedotto dalla tabella delle posizioni (BSEG o vista ACDOCA). Quando una posizione viene compensata, i campi Data di compensazione (AUGDT) e Documento di compensazione (AUGBL) vengono valorizzati per quella posizione. Acquisizione Utilizzi la data di compensazione (BSEG-AUGDT) della posizione come timestamp dell’evento. Tipo di evento inferred | |||
| Registrazione contabile creata | Questa attività indica 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. Questo è il punto di partenza del ciclo di vita della registrazione contabile. | ||
| Perché è importante Questo è il principale evento di avvio del processo. Analizzare il tempo che intercorre tra questo evento e la registrazione è fondamentale per misurare il tempo complessivo del ciclo e individuare i ritardi iniziali nell’inserimento dei dati. Dove reperirlo Questo evento può essere acquisito esplicitamente dalla tabella SAP BKPF utilizzando i campi della data di creazione (CPUDT) e dell’ora di creazione (CPUTM) per un determinato numero documento (BELNR). Acquisizione Utilizzi BKPF-CPUDT e BKPF-CPUTM per il timestamp dell’evento. Tipo di evento explicit | |||
| Registrazione contabile eseguita | La registrazione contabile viene registrata ufficialmente nel libro mastro, con impatto sui bilanci dell’azienda. È il momento in cui il documento diventa un record finanziario permanente. | ||
| Perché è importante Questo è il principale traguardo positivo e segna la fine del ciclo di elaborazione centrale. Analizzare la produttività delle registrazioni eseguite e il tempo necessario per raggiungere questa fase costituisce una metrica fondamentale del Process Mining. Dove reperirlo Si tratta di un evento esplicito, contrassegnato dalla data di registrazione (BUDAT) nella tabella BKPF. Un documento registrato presenta lo stato documento (BSTAT) vuoto, distinguendosi dai documenti parcheggiati («V») o sospesi («D»). Acquisizione Utilizzi la data di registrazione (BKPF-BUDAT) e la data di inserimento (BKPF-CPUDT) per assegnare il timestamp all’evento. Un valore BKPF-BSTAT vuoto indica un documento registrato. Tipo di evento explicit | |||
| Registrazione contabile inviata per la revisione | Il creatore della registrazione contabile invia formalmente il documento al Workflow di revisione e approvazione. Questa attività rappresenta 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 del ciclo di approvazione. Misurare il tempo da questo punto fino all’approvazione o al rifiuto finale aiuta a isolare i colli di bottiglia specifici delle fasi di revisione e approvazione. Dove reperirlo Questo evento viene spesso acquisito dai log del Workflow, nelle tabelle SWW_WIHEAD e SWWLOG, collegate all’oggetto di business. Può anche essere dedotto da una modifica dello stato in un campo personalizzato della testata del documento (BKPF). Acquisizione Timestamp della creazione dell’elemento di Workflow oppure modifica di un campo di stato in «Inviato» o «In revisione». Tipo di evento inferred | |||
| Documentazione di supporto allegata | Un utente allega uno o più documenti di supporto, come fatture o fogli di calcolo, alla registrazione contabile. In genere questa operazione serve a fornire prove e contesto per la transazione finanziaria durante la revisione e l’audit. | ||
| Perché è importante Garantire che la documentazione sia allegata prima della revisione è fondamentale per la conformità e l’efficienza delle approvazioni. Questa attività aiuta a misurare il rispetto delle policy sulla documentazione e il relativo impatto sui tempi del ciclo di approvazione. Dove reperirlo In genere questo evento viene dedotto verificando il timestamp di creazione degli allegati collegati tramite Generic Object Services (GOS). La tabella SRGBTBREL collega l’oggetto di business, ad esempio il documento BKPF, all’allegato. Acquisizione Interroghi le tabelle degli allegati GOS, ad esempio SRGBTBREL, per individuare i collegamenti all’oggetto BKPF e utilizzi il timestamp di creazione dell’allegato. Tipo di evento inferred | |||
| Registrazione contabile corretta | L’utente modifica una registrazione contabile dopo che è stata rifiutata o restituita per apportare modifiche. Questa attività rappresenta il lavoro di rilavorazione necessario per risolvere i problemi individuati durante la revisione prima di un nuovo invio. | ||
| 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 mette in evidenza le opportunità di formazione e chiarimento del processo. Dove reperirlo L’evento può essere dedotto monitorando la data «Ultima modifica» (AEDAT) nella tabella BKPF per un documento che si trovava precedentemente nello stato «Rifiutato». I documenti di modifica forniscono dettagli più specifici sulle modifiche apportate. Acquisizione Utilizzi il timestamp delle testate dei documenti di modifica (CDHDR-UDATE) per le modifiche effettuate dopo un evento di rifiuto. Tipo di evento inferred | |||
| Registrazione contabile modificata dopo la registrazione | Un utente modifica un insieme limitato di campi di una registrazione contabile dopo che questa è già stata registrata nel libro mastro. Sebbene la maggior parte dei dati finanziari sia immutabile dopo la registrazione, alcuni campi, come testo o assegnazioni, possono essere modificati. | ||
| Perché è importante Questa attività rappresenta un indicatore critico di conformità. Le modifiche successive alla registrazione possono indicare tentativi di alterare i record e devono essere monitorate attentamente per prevenire frodi e garantire l’integrità dei dati. Dove reperirlo L’evento può essere dedotto in modo affidabile dalle tabelle dei documenti di modifica (CDHDR e CDPOS). Una voce in CDHDR relativa al numero documento, con data di modifica successiva alla data di registrazione, indica una modifica successiva alla registrazione. Acquisizione Individui in CDHDR i record per i quali il timestamp della modifica (UDATE/UTIME) è successivo alla data di registrazione del documento (BKPF-BUDAT). Tipo di evento inferred | |||
| Registrazione contabile parcheggiata | Un utente salva una registrazione contabile incompleta senza registrarla, per poterla completare o sottoporre a revisione in un secondo momento. Si tratta di un’azione esplicita che crea un record di testata del documento con stato «parcheggiato», mantenendolo in uno stato non registrato. | ||
| Perché è importante Il parcheggio è un passaggio comune prima dell’invio. Monitorare la durata dello stato parcheggiato aiuta a individuare i ritardi nel completamento e nella preparazione dei dati prima dell’avvio formale della revisione e dell’approvazione. Dove reperirlo Nella tabella BKPF, un documento parcheggiato è identificato dal campo dello stato documento (BSTAT) con valore «V». Il timestamp dell’evento è la data di creazione (CPUDT). Acquisizione Filtri i documenti per i quali BKPF-BSTAT = «V» al momento della creazione. Tipo di evento explicit | |||
| Registrazione contabile rifiutata | Un revisore o approvatore rifiuta la registrazione contabile, impedendone la registrazione. In genere il documento viene restituito al creatore per la correzione, avviando un ciclo di rilavorazione. | ||
| Perché è importante Monitorare i rifiuti è fondamentale per comprendere la qualità del processo e individuare gli errori più comuni. Tassi di rifiuto elevati indicano problemi di accuratezza dei dati, comprensione delle policy o adeguatezza della documentazione di supporto. Dove reperirlo Questo evento viene dedotto da una modifica dello stato in un log del Workflow o in un campo di stato personalizzato del documento della registrazione contabile. I log dei documenti di modifica (CDHDR/CDPOS) relativi al campo di stato interessato possono fornire il timestamp. Acquisizione Identifichi la modifica del campo di stato in «Rifiutato» tramite i documenti di modifica (CDHDR/CDPOS) o i log del Workflow. Tipo di evento inferred | |||
| Registrazione manuale identificata | La registrazione contabile è stata eseguita utilizzando un codice transazione manuale anziché un’interfaccia automatizzata o un job batch. Non si tratta di un evento temporale, ma di una classificazione dell’attività di registrazione. | ||
| Perché è importante Identificare le registrazioni manuali è fondamentale per le iniziative di automazione. Un’elevata percentuale di registrazioni manuali suggerisce opportunità per semplificare i processi integrando i sottosistemi o utilizzando programmi di registrazione automatizzati. Dove reperirlo Questo dato viene calcolato analizzando il campo del codice transazione (TCODE) nella tabella di testata del documento (BKPF). Per classificare la registrazione viene utilizzato un elenco di T-Code manuali noti, come FB01, F-02 e FB50. Acquisizione Classifichi l’evento in base a BKPF-TCODE, confrontandolo con un elenco predefinito di codici transazione manuali al momento della registrazione. Tipo di evento calculated | |||
Guide all’estrazione
Passaggi
- Prerequisiti e accesso: verifichi di disporre di un utente con le autorizzazioni necessarie per interrogare il database sottostante di SAP S/4HANA o eseguire report ABAP. È necessario l’accesso in lettura alle CDS View I_JournalEntry, I_JournalEntryItem e alle tabelle CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ e SWWLOGHIST. L’accesso viene generalmente concesso tramite un client di database come SAP HANA Studio o DBeaver, oppure utilizzando SAP ABAP Development Tools (ADT) per Eclipse.
- Identificazione delle configurazioni specifiche del sistema: prima di eseguire la query, individui i codici attività specifici utilizzati nel Suo Workflow di approvazione dei Journal Entry. Si rivolga all’amministratore SAP del Workflow per individuare gli ID delle attività, ad esempio TS12345678, corrispondenti agli eventi di invio, rifiuto e approvazione. Questi valori sono necessari per sostituire i segnaposto nella query finale.
- Preparazione della query SQL: copi la query SQL completa fornita nella sezione
querynel client SQL o nello strumento di sviluppo scelto. - Impostazione dei parametri della query: individui i segnaposto presenti nella query e li sostituisca con i valori specifici del Suo sistema. È necessario impostare i parametri
[YourCompanyCode],[StartDate]e[EndDate]. Deve inoltre sostituire i segnaposto relativi agli ID delle attività del Workflow,[Workflow Submitted Task ID],[Workflow Rejected Task ID]e[Workflow Approved Task ID], con i valori identificati nel passaggio precedente. - Esecuzione della query di estrazione: esegua la query SQL modificata sul database SAP S/4HANA. In base all’intervallo di date e al volume dei dati, il completamento della query potrebbe richiedere molto tempo. Si consiglia di eseguirla negli orari di minore attività.
- Verifica dei risultati iniziali: al termine della query, esamini le prime righe dell’output per verificare che tutte le colonne, come JournalEntryId, ActivityName ed EventTime, siano valorizzate correttamente. Il set di risultati dovrebbe contenere una riga per ogni evento aziendale distinto nel ciclo di vita del Journal Entry.
- Esportazione dei dati in CSV: esporti l’intero set di risultati dallo strumento SQL in un unico file CSV. Verifichi che il file utilizzi la codifica UTF-8 per evitare problemi con i caratteri speciali.
- Preparazione del caricamento: prima di caricare il file in uno strumento di Process Mining, verifichi che il file CSV contenga le intestazioni richieste. I dati sono già strutturati come Event Log, pertanto non dovrebbe essere necessaria alcuna ulteriore trasformazione o riorganizzazione.
Configurazione
- Core Data Services (CDS) Views: l’estrazione utilizza principalmente
I_JournalEntryper i dati di testata eI_JournalEntryItemper i dettagli delle posizioni e degli importi. Queste viste offrono un’interfaccia semplificata e semanticamente ricca al universal journal (ACDOCA). - Tabelle di supporto: per ottenere una visione completa del processo, la query esegue inoltre il join di diverse tabelle SAP standard:
CDHDReCDPOSper tracciare le modifiche ai documenti.SRGBRELeSOODper identificare il momento in cui gli allegati vengono collegati tramite Generic Object Services (GOS).SWW_WI2OBJeSWWLOGHISTper estrarre gli eventi chiave dal Workflow 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 compreso tra 3 e 6 mesi. - Filtro organizzativo: applichi sempre il filtro
CompanyCodeper limitare l’estrazione alle entità giuridiche pertinenti. In un sistema di grandi dimensioni, interrogare contemporaneamente tutti i codici società può comportare tempi di esecuzione estremamente lunghi. - ID delle attività del Workflow: la query contiene segnaposto per gli ID delle attività del Workflow, ad esempio
[Workflow Approved Task ID]. Questi ID sono univoci per ogni installazione SAP e devono essere configurati correttamente affinché le attività del Workflow vengano estratte. In loro assenza, non verrà acquisito alcun evento di invio, approvazione o rifiuto. - Prerequisiti: l’utente che esegue l’estrazione deve disporre di ampie autorizzazioni di lettura per le tabelle finanziarie, di sistema e del Workflow. Queste autorizzazioni non sono standard e devono essere assegnate in modo specifico.
a 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 stato approvato e che l’utente incaricato dell’estrazione disponga dell’autorizzazione di lettura per BKPF e ACDOCA, oltre che per eventuali fonti configurate relative a Workflow, allegati, cronologia delle modifiche, compensazioni o storni richieste dal Suo sistema. L’accesso diretto al database viene normalmente eseguito con SAP HANA Database Explorer, SAP HANA Studio o un client SQL approvato. Non esegua query di estrazione in una transazione applicativa SAP, salvo che il Suo sistema supporti esplicitamente tale accesso.
- Verifichi lo schema fisico di BKPF e ACDOCA, inclusi il campo client, il campo codice società, il campo esercizio, il campo numero documento, il campo tipo documento, il campo data di registrazione, il campo data di creazione, il campo ora di creazione, il campo utente, il campo dell’importo in valuta locale e gli eventuali campi relativi a storni o compensazioni. Le implementazioni SAP S/4HANA possono differire per schema e disponibilità dei campi; sostituisca pertanto i segnaposto tra parentesi quadre nella query con campi verificati nel Suo sistema.
- Individui le fonti autorevoli per gli eventi di Workflow e allegati. BKPF e ACDOCA forniscono i dati dei documenti contabili e delle posizioni, ma da sole non espongono in modo affidabile ogni evento di parcheggio, invio, rifiuto, correzione, approvazione o allegato. Sostituisca i segnaposto tra parentesi quadre relativi alle fonti di Workflow e allegati con viste o tabelle approvate della Sua implementazione. Se una fonte non è disponibile, non inventi gli eventi. Configuri la fonte corrispondente oppure escluda l’attività previa approvazione documentata.
- Imposti i parametri di estrazione per l’intervallo di date, i codici società, i tipi documento e il client richiesti. Per la validazione iniziale si consiglia un intervallo compreso tra tre e sei mesi. Utilizzi l’intervallo dei timestamp degli eventi per gli eventi operativi e l’intervallo della data di registrazione per gli eventi contabili, in base all’ambito di processo concordato.
- Esegua la query SQL completa nel client SQL HANA approvato. La query crea una riga evento per ogni attività estratta esplicitamente. Utilizza BKPF e ACDOCA per gli eventi contabili e le viste fonte configurate per gli eventi di Workflow, allegati, modifiche, compensazioni e storni. Non deduce le attività dalla semplice esistenza di un documento.
- Verifichi 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 contengano 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 esercizi e l’intervallo di date selezionati. Riconcili separatamente le popolazioni relative a Workflow e allegati, poiché le relative regole di conservazione e timestamp possono differire da quelle dei dati contabili.
- Convalidi l’ordine degli eventi e la gestione dei duplicati. Le posizioni multiple in ACDOCA non devono creare eventi contabili duplicati, salvo che il disegno del processo richieda intenzionalmente eventi a livello di posizione. Utilizzi la logica di aggregazione della query per produrre un unico evento contabile per Journal Entry e tipo di evento, mantenendo, quando disponibili, gli identificativi degli eventi della fonte configurata.
- Esporti il risultato in formato 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 compreso tra tre e sei mesi. Utilizzi un intervallo più breve per i test delle prestazioni e lo estenda solo dopo aver convalidato il numero di righe e la copertura degli eventi.
- Ambito client e società: imposti [Client parameter] e limiti CompanyCode alle entità giuridiche richieste. Non ometta il predicato relativo al client in un sistema multi-client.
- Ambito contabile: configuri [Document type filter] e, ove opportuno, i filtri per esercizio e data di registrazione. Includa i documenti registrati e non registrati solo se la fonte selezionata li rappresenta in modo affidabile.
- Ambito Workflow: 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 rappresentano la creazione, l’esecuzione o il completamento dell’azione di Workflow.
- Ambito allegati: configuri [Attachment event source] e il campo di relazione che collega un allegato al Journal Entry. Verifichi se la fonte registra la creazione, la sostituzione o l’eliminazione dell’allegato.
- Ambito modifiche: configuri [Change history source] per le modifiche successive alla registrazione. Verifichi che la fonte identifichi il Journal Entry e fornisca un timestamp affidabile della modifica.
- Ambito compensazioni: configuri [Clearing source] e la relazione tra il documento contabile compensato e il documento di compensazione. Decida se assegnare l’evento al Journal Entry originale, al documento di compensazione o a entrambi.
- Ambito storni: configuri [Reversal source] e la relazione tra i documenti originale e di storno. La query assegna l’attività allo stesso JournalEntryId del documento originale quando tale relazione è disponibile.
- 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 della registrazione o un altro timestamp approvato.
- Importo in valuta: ACDOCA è basata sulle posizioni. La query aggrega gli importi in valuta locale per Journal Entry. Verifichi la convenzione dei segni e se includere le righe statistiche, specifiche del ledger o del ledger di estensione.
- Prestazioni: selezioni solo le colonne necessarie, applichi i filtri nelle fasi iniziali, eviti scansioni senza restrizioni di ACDOCA ed esegua la query durante una finestra di reporting approvata. Utilizzi il partition pruning tramite i predicati relativi a client, esercizio, codice società e data di registrazione, quando supportato.
- 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 di Workflow realmente distinte.
- Prerequisiti: autorizzazioni database necessarie, connettività SAP HANA approvata, accesso alle fonti configurate per Workflow e allegati, configurazione appropriata di SAP Financial Accounting e del Workflow, nonché un formato di esportazione supportato da ProcessMind.
a 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
- Creazione del programma ABAP: acceda all’ABAP Editor tramite il codice transazione
SE38. Inserisca un nome per il nuovo programma, ad esempioZ_PM_JE_EXTRACT, e faccia clic su «Crea». Indichi un titolo appropriato, imposti «Tipo» su «Programma eseguibile» e salvi il programma come oggetto locale o all’interno di un package. - Definizione della schermata di selezione: nel programma, definisca parametri e select-options che consentano agli utenti di filtrare i dati. Dovranno includere un intervallo di date per la data di creazione del Journal Entry (
P_CPUDT_FR,P_CPUDT_TO), una select-option per il codice società (SO_BUKRS) e un percorso file per l’output sul server applicativo (P_FPATH). - Dichiarazione delle strutture dati: definisca una struttura di tabella interna corrispondente al formato richiesto per l’Event Log. Questa struttura conterrà l’output finale. Dichiari inoltre tabelle interne e aree di lavoro per le tabelle SAP da cui verranno selezionati i dati, come BKPF, ACDOCA, CDHDR, CDPOS e diverse tabelle del Workflow.
- Implementazione della logica di selezione dei dati: scriva la logica ABAP principale per recuperare i dati relativi a ciascuna delle 12 attività richieste. Crei subroutine separate (FORM) per ogni attività, così da mantenere il codice organizzato. Ad esempio, crei un FORM per
get_created_events,get_parked_events,get_workflow_eventse così via. - Selezione degli eventi «Created» e «Posted»: legga dalla tabella BKPF in base ai criteri definiti nella schermata di selezione dell’utente. Una voce in BKPF indica la creazione. Un documento con stato
BSTAT = ' 'è considerato registrato. Utilizzi il timestamp di creazione (CPUDT,CPUTM) come orario dell’evento. - Selezione degli eventi «Parked»: legga dalla tabella VBKPF, che memorizza le testate dei documenti parcheggiati. Il timestamp di creazione in questa tabella rappresenta l’evento di parcheggio.
- Selezione degli eventi di Workflow «Submitted», «Approved» e «Rejected»: interroghi tabelle del Workflow come SWW_WI2OBJ, per collegare un oggetto Journal Entry a un’istanza del Workflow, e SWWLOGHIST o SWWIHEAD, per ottenere i dettagli e la tempistica dei singoli passaggi. Dovrà individuare gli ID specifici delle attività di Workflow per l’invio, l’approvazione e il rifiuto nel Suo sistema.
- Selezione degli eventi «Change» e «Correction»: interroghi le tabelle dei documenti di modifica CDHDR, testata, e CDPOS, posizione, per
OBJECTCLAS = 'BELEG'. Per «Changed After Posting», filtri le modifiche il cui timestamp è successivo alla data di registrazione del documento. Per «Corrected», filtri le modifiche ai documenti parcheggiati o rifiutati. - Selezione degli eventi «Reversal» e «Cleared»: identifichi gli storni individuando i documenti in cui il campo
STBLG, numero del documento stornato, in BKPF è valorizzato. L’orario dell’evento di storno è l’orario di creazione del documento di storno. Identifichi gli eventi di compensazione selezionando la data di compensazione più recente (AUGDT) dalla tabella ACDOCA per le posizioni di un determinato Journal Entry. - Unione e ordinamento dei dati: man mano che seleziona i dati di ciascuna attività, aggiunga i risultati alla tabella interna master finale. Al termine di tutte le selezioni, ordini la tabella master per
JournalEntryIdedEventTimeper garantire l’ordine cronologico di ogni caso. - Generazione del file di output: utilizzi le istruzioni
OPEN DATASET,LOOP AT... TRANSFEReCLOSE DATASETper scrivere il contenuto della tabella interna finale ordinata nel percorso file specificato sul server applicativo SAP. Il file deve essere in formato CSV e contenere una riga di intestazione. - Pianificazione dell’esecuzione: per le estrazioni ricorrenti, 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 il processo di esportazione dei dati sarà automatizzato.
Configurazione
- Intervallo di date: la schermata di selezione deve prevedere un intervallo di date obbligatorio per la data di creazione del Journal Entry (
CPUDT). Si consiglia di estrarre i dati in blocchi gestibili, ad esempio di 3-6 mesi alla volta, per garantire buone prestazioni. - Codice società (
BUKRS): si tratta di un filtro fondamentale per limitare l’estrazione alle specifiche entità giuridiche pertinenti all’analisi di Process Mining. Non è consigliabile estrarre contemporaneamente i dati di tutti i codici società. - Tipo documento (
BLART): può aggiungere questo filtro opzionale per concentrarsi su specifici tipi di Journal Entry, ad esempio «SA» per le registrazioni nel conto Co.Ge. o «KR» per le fatture fornitore. In questo modo può ridurre il volume dei dati e aumentare la rilevanza del dataset. - Percorso file: il programma richiede un percorso file logico sul server applicativo SAP in cui scrivere il file di output. Verifichi che il percorso sia valido e che l’utente del sistema SAP disponga delle autorizzazioni di scrittura necessarie per la directory. Utilizzi la transazione
AL11per gestire e visualizzare le directory del server. - ID delle attività del Workflow: la logica per estrarre gli eventi di Workflow, «Submitted», «Approved» e «Rejected», deve essere configurata con gli ID specifici delle attività utilizzate nel Workflow di approvazione dei Journal Entry della Sua organizzazione. Spesso si tratta di ID personalizzati, che devono essere individuati da un consulente o sviluppatore del Workflow.
- 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 del Workflow (SWW*).
a 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 per iniziare?
Utilizzi questo Template per preparare i Suoi dati con sicurezza e ottenere insight fondamentali sul processo Record to Report - Journal Entry. Inizi oggi il Suo percorso verso l’eccellenza dei processi.
Semplifichi il Journal Entry Record to Report per ottenere la massima efficienza
Trasformi il Suo processo e riduca del 30% il tempo di ciclo del Journal Entry Record to Report.
Non è richiesta alcuna carta di credito. Configurazione in pochi minuti.