Il template dei dati per il processo Record to Report - Journal Entry
Il template dei dati per il processo Record to Report - Journal Entry
- Attributi consigliati per un'analisi completa
- Attività chiave delle registrazioni da monitorare
- Guida pratica all'estrazione dati per SAP ECC
Attributi Record to Report - Registrazioni Contabili
| Nome | Descrizione | ||
|---|---|---|---|
| ID Registrazione contabile JournalEntryId | L'identificatore univoco di un documento contabile, che combina società, numero documento ed esercizio. | ||
| Descrizione L'ID Registrazione è l'identificativo principale per tracciare il ciclo di vita di una registrazione contabile. È una chiave composta, solitamente formata dalla Società (BUKRS), Numero Documento (BELNR) ed Esercizio (GJAHR) per garantirne l'univocità. Nell'analisi del processo, questo ID collega tutte le attività correlate. Tracciandolo, possiamo ricostruire il percorso end-to-end di ogni registrazione, misurare i tempi di ciclo e identificare deviazioni o colli di bottiglia per singole operazioni. Perché è importante È la chiave essenziale per tracciare una registrazione dalla creazione alla contabilizzazione finale, permettendo l'analisi end-to-end e il confronto delle varianti. Dove trovare Si tratta di un attributo derivato, in genere una concatenazione di campi dalla tabella BKPF: Società (BUKRS), Numero Documento (BELNR) ed Esercizio (GJAHR). Esempi 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Nome attività ActivityName | Il nome dell'attività commerciale o dell'evento verificatosi in un punto specifico del processo di registrazione. | ||
| Descrizione Il Nome Attività descrive un passaggio specifico nel ciclo di vita della registrazione, come 'Registrazione creata', 'Registrazione approvata' o 'Registrazione contabilizzata'. Questo attributo è in genere derivato da più fonti in SAP, inclusi i codici transazione (TCODE), i log dei documenti di modifica (tabelle CDHDR e CDPOS) e i campi di stato del documento. L'analisi delle attività è il cuore del Process Mining. Consente di visualizzare le mappe di processo, calcolare i tempi di transizione tra le fasi e identificare i loop di rilavorazione (ad esempio, 'Registrazione rifiutata' seguita da 'Registrazione corretta'). Questi dati sono fondamentali per le dashboard relative ai tempi di ciclo, ai tassi di rilavorazione e alle varianti di processo. Perché è importante Definisce le fasi nella mappa di processo, rendendo possibile visualizzare, analizzare e ottimizzare il workflow delle registrazioni contabili. Dove trovare Derivato da varie fonti, inclusi i codici transazione in BKPF (TCODE), lo stato del documento e i log del workflow in tabelle come SWW_WI2OBJ, o i documenti di modifica in CDHDR e CDPOS. Esempi Registrazione Contabile CreataRegistrazione contabile approvataRegistrazione contabile rifiutataRegistrazione contabile contabilizzata | |||
| Timestamp Evento EventTime | Il timestamp che indica quando si è verificata una specifica attività o evento per la registrazione. | ||
| Descrizione Event Time fornisce la data e l'ora esatte per ogni attività nel processo di registrazione contabile. Questi dati sono fondamentali per calcolare tutte le metriche basate sul tempo, come i cycle time, le durate di elaborazione e i ritardi tra le fasi. La fonte di questo timestamp varia a seconda dell'attività; può essere la data/ora di creazione del documento (CPUDT/CPUTM) o i timestamp di modifica dai log (CDHDR-UDATE/UTIME). Nell'analisi, Event Time viene utilizzato per ordinare gli eventi cronologicamente, formando la base della mappa del processo. È essenziale per calcolare tutti i KPI legati al tempo, come l'Average Journal Entry Cycle Time, l'Average Approval Time e il Time from Approval to Posting. Perché è importante Questo timestamp è la base per ogni analisi temporale, consentendo il calcolo dei tempi di ciclo, delle durate e l'individuazione dei colli di bottiglia. Dove trovare Estratto da vari campi a seconda dell'attività, principalmente timestamp di creazione (CPUDT, CPUTM) da BKPF o timestamp dei documenti di modifica (UDATE, UTIME) da CDHDR. Esempi 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| Sistema di Origine SourceSystem | Il sistema da cui sono stati estratti i dati di processo. | ||
| Descrizione Questo attributo identifica l'origine dei dati, in questo caso la specifica istanza SAP ECC. In genere è un valore statico aggiunto durante l'estrazione. Nonostante la semplicità, è importante in ambienti con più ERP o fonti dati. Garantisce la chiarezza della discendenza dei dati e permette di filtrare l'analisi per sistema di origine. Perché è importante Fornisce una chiara discendenza dei dati ed è essenziale per monitorare la qualità dei dati, specialmente in ambienti con più sistemi sorgente. Dove trovare Si tratta solitamente di un valore statico aggiunto durante la trasformazione dei dati per identificare l'istanza SAP ECC (es. 'ECC_PROD_100'). Esempi SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Ultimo `Data Update` LastDataUpdate | Il timestamp che indica l'ultima estrazione o aggiornamento dei dati dal sistema di origine. | ||
| Descrizione Questo attributo registra data e ora dell'ultima estrazione dati da SAP ECC. È un metadato critico per capire quanto siano aggiornati i dati analizzati. In qualsiasi analisi di Process Mining, conoscere l'ora dell'ultimo aggiornamento è fondamentale per fidarsi dei dati e prendere decisioni informate, rispondendo alla domanda: "Quanto sono recenti queste informazioni?". Perché è importante Informa gli utenti sull'aggiornamento dei dati, assicurando che comprendano l'arco temporale dell'analisi e possano fidarsi dei risultati. Dove trovare Si tratta di un campo di metadati generato dallo strumento di estrazione dati o dal processo ETL al momento dell'aggiornamento dei dati. Esempi 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Codice Società CompanyCode | L'unità organizzativa che rappresenta un'entità legale indipendente per la quale viene redatto il bilancio. | ||
| Descrizione La Società è un'unità organizzativa fondamentale in SAP Financials. Rappresenta un'entità legale indipendente ed è un campo chiave nella testata del documento contabile. Questo attributo è essenziale per segmentare l'analisi dei processi per entità legale. Permette di confrontare le prestazioni dei processi, i tassi di conformità e i risultati dei KPI tra le diverse aree del business. Ad esempio, aiuta a identificare se i ritardi nell'approvazione o gli alti tassi di storno sono specifici di determinate società. Perché è importante Consente di filtrare e confrontare le prestazioni del processo tra diverse entità legali o business unit all'interno dell'organizzazione. Dove trovare Situato nella tabella di testata documento BKPF, campo BUKRS. Esempi 10002000US01DE01 | |||
| Codice transazione TransactionCode | Il codice transazione SAP utilizzato per creare o elaborare la registrazione contabile. | ||
| Descrizione Il Codice Transazione (T-Code) identifica una funzione specifica in SAP. Indica come è stata creata la registrazione: ad esempio manualmente (FB01, F-02), tramite sospensione (FV50) o interfaccia automatica. Questo attributo è prezioso per l'ottimizzazione delle attività manuali. Analizzando il T-Code, possiamo distinguere tra processi manuali e automatici, capire quali passaggi manuali richiedono più tempo e individuare opportunità di automazione per migliorare l'efficienza. Perché è importante Aiuta a distinguere tra processi manuali e automatizzati, identificando opportunità di automazione e standardizzazione dei processi. Dove trovare Situato nella tabella di testata documento BKPF, campo TCODE. Esempi FB01F-02FV50FBD1 | |||
| Data di Registrazione PostingDate | La data in cui l'operazione viene registrata nel libro giornale, con effetto sul periodo contabile. | ||
| Descrizione La Data di Registrazione determina il periodo fiscale in cui viene contabilizzata l'operazione. È un campo critico per la conformità, poiché deve allinearsi alle scadenze di chiusura del periodo contabile. Nel Process Mining, questa data è usata per monitorare la conformità. La dashboard di monitoraggio e i KPI di aderenza usano questo attributo per verificare se le registrazioni sono contabilizzate nel periodo corretto e per analizzare i trend dei volumi nel tempo. Perché è importante Fondamentale per il reporting finanziario e l'analisi di conformità, garantendo che le registrazioni siano contabilizzate nel periodo contabile corretto. Dove trovare Situato nella tabella di testata documento BKPF, campo BUDAT. Esempi 2023-10-312023-11-302024-01-15 | |||
| È Stornata IsReversed | Un flag booleano che indica se la registrazione contabile è stata stornata. | ||
| Descrizione Questo flag identifica le registrazioni che sono state stornate. In SAP, un documento stornato è collegato al documento di storno, garantendo la tracciabilità. È fondamentale per la dashboard di analisi degli storni e per il relativo KPI. Permette di isolare le voci stornate per indagare le cause (es. errori di inserimento o trattamenti contabili errati), con l'obiettivo di ridurne la frequenza. Perché è importante Supporta direttamente l'analisi degli storni contrassegnando le registrazioni che sono state successivamente annullate, aiutando a identificare le cause radice degli errori e a migliorare l'integrità dei dati. Dove trovare Derivato dal campo del numero del documento di storno (STBLG) nella tabella BKPF. Se STBLG non è vuoto, il flag è vero. Esempi truefalse | |||
| Tipo Documento DocumentType | Una classificazione per i documenti contabili che controlla il modo in cui vengono elaborati e archiviati. | ||
| Descrizione Il Tipo Documento distingue i diversi tipi di operazioni commerciali, come una registrazione di contabilità generale (SA), una fattura fornitore (KR) o una registrazione cespiti (AA). Viene assegnato a ogni registrazione contabile. Si tratta di un attributo critico per l'analisi perché permette di segmentare il processo in base alla natura dell'operazione. Le dashboard sul throughput e i KPI sui tempi medi di ciclo dipendono direttamente da questo campo, aiutando a scoprire se certi tipi di registrazioni sono più inclini a ritardi o rilavorazioni. Perché è importante Consente la segmentazione dell'analisi per tipo di transazione, aiutando a identificare se i problemi del processo sono specifici di determinati tipi di registrazioni. Dove trovare Situato nella tabella di testata documento BKPF, campo BLART. Esempi SAKRREAA | |||
| Utente User | L'ID utente SAP della persona che ha creato o modificato la registrazione. | ||
| Descrizione Questo attributo cattura il nome utente SAP responsabile di un'attività. Viene estratto direttamente dalla testata del documento o dalle tabelle dei log. Analizzare l'attributo Utente è fondamentale per comprendere le prestazioni del team e dei singoli. Supporta la dashboard di produttività tracciando volumi e tempi di elaborazione per utente. Aiuta anche a identificare chi è coinvolto in loop di rilavorazione, storni o deviazioni, permettendo formazione mirata. Perché è importante Identifica l'utente responsabile di ogni attività, consentendo l'analisi delle prestazioni, della distribuzione del carico di lavoro e dei pattern di rilavorazione. Dove trovare In genere dalla tabella BKPF (campo USNAM per il creatore) o dalla tabella CDHDR (campo USERNAME per chi ha effettuato la modifica). Esempi ABROWNCJONESDSMITH | |||
| Centro di Costo CostCenter | Un'unità organizzativa all'interno di un'area di controllo che rappresenta un luogo in cui vengono sostenuti i costi. | ||
| Descrizione Il Centro di Costo è un elemento chiave dell'anagrafica del modulo Controlling (CO), spesso assegnato a livello di singola voce della registrazione contabile. Viene utilizzato per tracciare i costi per un dipartimento, una funzione o una sede specifica. Includere il Centro di Costo permette un'analisi più granulare. Può aiutare a determinare se certi reparti generano più rilavorazioni, hanno tempi di ciclo più lunghi o sono responsabili di un volume maggiore di inserimenti manuali, fornendo una visione dell'efficienza per singolo dipartimento. Perché è importante Consente l'analisi delle prestazioni del processo per dipartimento o area funzionale, aiutando a individuare inefficienze localizzate. Dove trovare Situato nella tabella delle voci di documento BSEG, campo KOSTL. Esempi 4100CC_FINANCE_US10010101 | |||
| Chiave Valuta CurrencyKey | Il codice valuta per gli importi registrati nella prima nota. | ||
| Descrizione Questo attributo specifica la valuta della registrazione (es. USD, EUR, JPY). Fornisce il contesto per gli importi finanziari associati. Anche se non è sempre una dimensione primaria, è cruciale per interpretare correttamente i valori monetari e può essere usato per segmentare l'analisi in organizzazioni globali, verificando se i processi variano tra valute locali ed estere. Perché è importante Fornisce il contesto necessario per tutti i valori monetari, garantendo un'analisi finanziaria e un'interpretazione accurate. Dove trovare Situato nella tabella di testata documento BKPF, campo WAERS. Esempi USDEURGBPJPY | |||
| È una Rilavorazione IsRework | Un flag booleano che indica se una registrazione contabile ha subito un loop di rilavorazione, ad esempio se è stata rifiutata e poi corretta. | ||
| Descrizione Questo flag identifica i casi che hanno deviato dal percorso ideale richiedendo azioni correttive. In genere è impostato su true se si osserva una sequenza come 'Registrazione rifiutata' seguita da 'Registrazione corretta'. L'attributo è essenziale per calcolare il KPI del tasso di rilavorazione e per l'analisi nella dashboard dei rifiuti. Aiuta a quantificare l'inefficienza e fornisce una base per indagare le cause delle rilavorazioni, come requisiti poco chiari. Perché è importante Contrassegna le registrazioni che hanno richiesto una correzione, consentendo la quantificazione delle rilavorazioni e l'analisi delle loro cause radice per migliorare i tassi di "giusto al primo colpo". Dove trovare Si tratta di un attributo calcolato analizzando la sequenza delle attività. Un loop di rilavorazione viene identificato se si verifica un'attività di rifiuto o correzione. Esempi truefalse | |||
| Importo totale documento TotalDocumentAmount | Il valore totale della registrazione nella valuta del documento. | ||
| Descrizione Questo attributo rappresenta il valore finanziario totale della registrazione. In genere è calcolato sommando i valori assoluti di tutte le voci di dare o avere associate al documento. Analizzare il processo per valore può rivelare pattern importanti: le registrazioni di alto valore potrebbero seguire percorsi di approvazione più rigidi. Permette di vedere se i tempi di ciclo o i tassi di rifiuto sono correlati all'importo della registrazione. Perché è importante Consente l'analisi dell'impatto finanziario, correlando ad esempio i tempi di elaborazione o i tassi di rifiuto con il valore monetario delle registrazioni contabili. Dove trovare Si tratta di un campo calcolato aggregando il campo importo (WRBTR o DMBTR) di tutte le voci nella tabella BSEG per una determinata registrazione. Esempi 1500.0025000.75125.50 | |||
| In sospeso IsParked | Un flag booleano che indica se la registrazione contabile è stata salvata come documento in sospeso (parked) prima della contabilizzazione. | ||
| Descrizione Mettere in sospeso (parking) un documento consente all'utente di salvare una registrazione incompleta senza influire sui saldi finanziari. Può essere completata o revisionata in seguito. Questo flag identifica le voci che sono passate per questa fase. Analizzare questo attributo aiuta a capire l'uso della funzione di sospensione. Può rivelare se viene utilizzata come fase di revisione informale, causando potenziali ritardi. Supporta l'analisi del tempo di ciclo end-to-end, distinguendo tra registrazioni dirette e pre-registrate. Perché è importante Identifica le registrazioni che utilizzano la funzione di sospensione, che può essere fonte di ritardi o indicatore di un processo di revisione informale. Dove trovare Derivato dal campo dello stato del documento (BSTAT) nella tabella BKPF. 'V' indica un documento in sospeso (parked). Esempi truefalse | |||
| Motivo dello Storno ReversalReason | Un codice che indica il motivo per cui una registrazione contabile è stata stornata. | ||
| Descrizione Quando un documento viene stornato, SAP consente all'utente di specificare un codice motivo. Questo codice fornisce informazioni strutturate sul perché lo storno si è reso necessario, ad esempio una data di registrazione errata o un errore di inserimento dati. Questo attributo è un input fondamentale per la dashboard 'Journal Entry Reversal Analysis'. Analizzando i motivi di storno più comuni, le aziende possono identificare problemi sistemici nei processi o lacune nella formazione e intraprendere azioni mirate per prevenire errori futuri e ridurre il tasso di storno. Perché è importante Fornisce informazioni dirette sul perché avvengono gli storni, consentendo un'analisi mirata delle cause per ridurre errori futuri. Dove trovare Situato nella tabella di testata documento BKPF, campo STGRD. Esempi 010205 | |||
| Tempo di approvazione ApprovalTime | Il tempo trascorso dal momento in cui una registrazione viene inviata per l'approvazione fino alla sua approvazione o rifiuto. | ||
| Descrizione Questa metrica misura la durata del sottoprocesso di approvazione, che spesso incide in modo significativo sul tempo di ciclo totale. Si calcola come la differenza temporale tra l'attività 'Journal Entry Submitted' e la relativa attività 'Journal Entry Approved' o 'Journal Entry Rejected'. L'Approval Time è la metrica centrale per la dashboard 'Journal Entry Approval Performance' e per il KPI 'Average Journal Entry Approval Time'. Analizzare questa durata aiuta a individuare i colli di bottiglia nel workflow di approvazione, misurare le performance degli approvatori e giustificare modifiche al processo, come l'adeguamento delle soglie di approvazione. Perché è importante Quantifica la durata della fase di approvazione, aiutando a individuare e risolvere i ritardi nel workflow di revisione. Dove trovare Calcolato sottraendo il timestamp dell'evento 'Journal Entry Submitted' da quello dell'evento 'Journal Entry Approved' o 'Journal Entry Rejected'. Esempi P1DT2HPT4H15MP3D | |||
| Tempo di Ciclo CycleTime | Il tempo totale trascorso dalla creazione della prima attività di registrazione fino alla contabilizzazione finale. | ||
| Descrizione Il Cycle Time è un indicatore chiave di prestazione che misura la durata end-to-end del processo di registrazione contabile. Viene calcolato calcolando la differenza tra il timestamp dell'evento finale di contabilizzazione e l'evento iniziale di creazione per una singola registrazione. Questa metrica calcolata è la misura principale nella dashboard 'Journal Entry End-to-End Cycle Time' e nel KPI 'Average Journal Entry Cycle Time'. Fornisce una visione d'insieme dell'efficienza complessiva del processo e viene utilizzata per monitorare l'impatto delle iniziative di miglioramento nel tempo. Perché è importante Misura l'efficienza complessiva end-to-end del processo, fornendo una metrica chiave per identificare i colli di bottiglia e monitorare i miglioramenti. Dove trovare Calcolato sottraendo il timestamp del primo evento dal timestamp dell'ultimo evento per ogni case (JournalEntryId). Esempi P2DT3H15MPT8H30MP5D | |||
Attività Record to Report - Registrazioni Contabili
| Activity | Descrizione | ||
|---|---|---|---|
| Registrazione contabile approvata | Questa attività segna l'approvazione finale di una registrazione nel workflow, rendendola pronta per la contabilizzazione. L'evento viene acquisito dal log del workflow al completamento della fase di rilascio. | ||
| Perché è importante È un traguardo chiave che conclude l'approvazione. La durata fino a questa attività è un KPI critico per l'efficienza, mentre il tempo da qui alla contabilizzazione misura il ritardo post-approvazione. Dove trovare Dedotto dal timestamp di completamento dell'ultima fase di approvazione nel log di SAP Business Workflow. Questa è l'ultima azione di approvazione prima che il documento venga contabilizzato o reso pronto per la registrazione. Acquisisci Identificazione del completamento della fase finale di 'rilascio' o 'approvazione' nei log del workflow. Tipo di evento inferred | |||
| Registrazione contabile contabilizzata | Questa è l'attività centrale in cui la registrazione viene inserita ufficialmente nel libro giornale, con impatto sul bilancio. Viene acquisita quando lo stato è 'contabilizzato' e viene assegnata una data di registrazione. | ||
| Perché è importante È il traguardo più importante, che indica la corretta elaborazione della registrazione. Il tempo di ciclo end-to-end è spesso misurato fino a questo punto, fondamentale per l'analisi della chiusura finanziaria. Dove trovare Identificato quando un documento nella tabella BKPF presenta una data di registrazione (BKPF-BUDAT). Per i documenti in sospeso, questo corrisponde al momento in cui lo stato BKPF-BSTAT passa da 'V' a vuoto. Il timestamp della registrazione è la data di inserimento BKPF-CPUDT. Acquisisci Identificazione di quando BKPF-BSTAT passa da 'V' a vuoto o, per le registrazioni dirette, dell'evento di creazione. Tipo di evento explicit | |||
| Registrazione contabile in sospeso | Questa attività segna la creazione iniziale di una registrazione in uno stato preliminare. Viene catturata esplicitamente in SAP quando un utente salva un documento tramite una transazione di sospensione (parking), impostando lo stato su 'in sospeso'. | ||
| Perché è importante È un evento di inizio critico per i processi che richiedono revisione. Analizzare il tempo tra la sospensione e la registrazione aiuta a identificare i ritardi nelle fasi preliminari e di approvazione. Dove trovare L'evento è identificato dalla testata BKPF. Un documento è considerato in sospeso quando è creato con stato BKPF-BSTAT = 'V'. Il timestamp è dato da data e ora di creazione (BKPF-CPUDT e BKPF-CPUTM). Acquisisci Identificazione della creazione del documento in BKPF dove BKPF-BSTAT è 'V'. Tipo di evento explicit | |||
| Registrazione contabile inviata | Questa attività indica che una registrazione in sospeso è stata finalizzata dal creatore ed è pronta per la revisione. In genere viene catturata dall'avvio di un task di SAP Business Workflow associato al documento. | ||
| Perché è importante Segna il passaggio dal creatore all'approvatore, avviando il calcolo per i KPI sui tempi di approvazione. È un traguardo fondamentale per misurare l'efficienza del workflow. Dove trovare Dedotto dall'ora di inizio dell'istanza del workflow di approvazione collegata all'oggetto documento finanziario. Ciò richiede l'analisi delle tabelle dei log del workflow come SWW_WI2OBJ per trovare il workflow avviato per la specifica società, numero documento ed esercizio. Acquisisci Identificazione dell'evento di inizio workflow per l'oggetto documento in sospeso. Tipo di evento inferred | |||
| Storno registrazione elaborato | Questa attività segna lo storno di una registrazione precedentemente contabilizzata. Lo storno è un nuovo documento contabile che annulla quello originale. | ||
| Perché è importante Questo è un evento critico per misurare la qualità dei dati. Un alto tasso di storni indica problemi sistemici nelle fasi iniziali di inserimento o approvazione, e ogni storno rappresenta una rilavorazione. Dove trovare L'evento è identificato nella testata del documento originale (tabella BKPF). Quando un documento viene stornato, SAP popola il numero del documento di storno (BKPF-STBLG) e il motivo (BKPF-STGRD). Il timestamp è la data di registrazione del nuovo documento di storno. Acquisisci Identificazione di quando BKPF-STBLG viene popolato nel documento originale; il timestamp è la data di registrazione del documento di storno. Tipo di evento explicit | |||
| Documentazione allegata | Questa attività rappresenta un utente che allega documenti di supporto, come fatture o fogli di calcolo. L'evento non è registrato esplicitamente e viene solitamente dedotto verificando la creazione di allegati collegati al documento contabile. | ||
| Perché è importante Tracciare questa attività aiuta a verificare la conformità alle policy che richiedono documentazione. I ritardi nel caricamento degli allegati possono essere la causa principale di cicli di approvazione prolungati. Dove trovare È difficile da catturare in modo affidabile come evento. Può essere dedotto analizzando le tabelle degli allegati GOS (es. SOOD) e collegando il timestamp di creazione all'ID della registrazione. Acquisisci Deduzione dal timestamp di creazione degli oggetti collegati nelle tabelle GOS (es. SOOD). Tipo di evento inferred | |||
| Identificata registrazione intersocietaria | Un'attività calcolata che contrassegna una registrazione contabile che interessa più di una società. Viene determinata analizzando le posizioni di un singolo documento contabile. | ||
| Perché è importante Le transazioni intersocietarie possono avere requisiti di elaborazione e approvazione più complessi. Identificarle consente un'analisi separata dei loro tempi di ciclo e dei percorsi di processo per trovare bottleneck specifici. Dove trovare Calcolato esaminando la tabella delle posizioni BSEG per un dato numero di documento (BELNR). Se le posizioni contengono più di una società distinta (BSEG-BUKRS), la registrazione è una scrittura intersocietaria. Acquisisci Verifica se esistono più valori univoci di BSEG-BUKRS per un singolo BKPF-BELNR. Tipo di evento calculated | |||
| Inserimento manuale identificato | Questa attività identifica se una registrazione è stata creata tramite una transazione manuale online rispetto a un'interfaccia automatica o un processo batch. Non è un'azione utente ma un attributo calcolato dai dati di sistema. | ||
| Perché è importante Distinguere tra registrazioni manuali e automatizzate è fondamentale per un miglioramento mirato dei processi. I processi manuali sono spesso al centro delle iniziative di standardizzazione e automazione. Dove trovare Viene calcolato analizzando i campi in BKPF. I codici transazione (BKPF-TCODE) come 'FB01', 'FB50' o 'FV50' indicano inserimenti manuali, mentre altri codici o nomi batch (BKPF-AWKEY) suggeriscono l'automazione. Acquisisci Derivato da BKPF-TCODE o da altri indicatori del sistema sorgente nella testata del documento. Tipo di evento calculated | |||
| Modifiche richieste alla registrazione contabile | Rappresenta un punto nel workflow in cui un approvatore ha revisionato la registrazione e l'ha rimandata al creatore per correzioni. Questo evento è catturato dai log del workflow che indicano un 'rifiuto' o un 'invio indietro'. | ||
| Perché è importante Questa attività è essenziale per identificare i loop di rilavorazione, fonte primaria di inefficienza. Un'alta frequenza di questo evento indica problemi nella qualità dei dati o requisiti poco chiari. Dove trovare L'evento è dedotto dal timestamp di una specifica fase di decisione utente nel log di SAP Business Workflow corrispondente a un'azione di 'rifiuto' o 'invio per correzione'. Acquisisci Identificazione del timestamp della decisione di 'rifiuto' o 'rilavorazione' nei log del workflow. Tipo di evento inferred | |||
| Registrazione contabile corretta | Questa attività indica che il creatore originale ha modificato una registrazione in sospeso dopo che è stata rimandata indietro. Viene dedotta rilevando modifiche al documento dopo un evento 'Modifiche richieste'. | ||
| Perché è importante Il monitoraggio delle correzioni aiuta a quantificare l'impegno dedicato ai rework. Il tempo che intercorre tra una richiesta di modifica e la correzione evidenzia i ritardi nella risoluzione dei problemi relativi alle voci inviate. Dove trovare Dedotto analizzando i log dei documenti di modifica (tabelle CDHDR e CDPOS) per il documento in sospeso. Una modifica registrata dopo un evento di rifiuto nel workflow indica che è stata apportata una correzione. Il timestamp proviene dalla tabella CDHDR. Acquisisci Identificazione della voce nel log delle modifiche in CDHDR/CDPOS dopo un evento di rifiuto. Tipo di evento inferred | |||
| Registrazione Contabile Creata | Rappresenta la creazione di una registrazione contabilizzata direttamente, senza una fase di sospensione. Viene catturata quando un documento è creato in SAP tramite una transazione di registrazione diretta. | ||
| Perché è importante Questa attività funge da punto di partenza alternativo per processi più semplici che non richiedono approvazione, aiutando a distinguere tra registrazioni dirette e pre-registrazioni complesse. Dove trovare Questo evento corrisponde alla creazione del documento nella tabella BKPF dove lo stato BKPF-BSTAT è vuoto (contabilizzato). Il timestamp è la data di creazione BKPF-CPUDT. Per questi documenti, gli eventi 'Creato' e 'Contabilizzato' avvengono simultaneamente. Acquisisci Identificazione della creazione del documento in BKPF dove BKPF-BSTAT è vuoto. Tipo di evento explicit | |||
| Registrazione contabile in sospeso eliminata | Rappresenta l'eliminazione di una registrazione in sospeso che non è mai stata contabilizzata. Può accadere dopo un rifiuto o se la registrazione è stata creata per errore. | ||
| Perché è importante Questa attività segna una fine non riuscita del processo. Analizzare perché i documenti in sospeso vengono eliminati può rivelare problemi come inserimenti duplicati o incomprensioni procedurali. Dove trovare L'evento è catturato quando cambia lo stato di un documento in sospeso nella tabella BKPF. Il campo BKPF-BSTAT viene aggiornato a 'Z' (Documento in sospeso eliminato). Il timestamp si trova nei log delle modifiche (CDHDR). Acquisisci Identificazione di quando BKPF-BSTAT viene aggiornato a 'Z'. Tipo di evento explicit | |||
| Registrazione contabile rifiutata | Questa attività indica il rifiuto finale di una registrazione. In genere è uno stato terminale nel workflow di approvazione, che porta alla successiva eliminazione del documento in sospeso. | ||
| Perché è importante Tracciare i rifiuti è fondamentale per la gestione della qualità. Analizzare i motivi e la frequenza dei rifiuti aiuta a migliorare il tasso di first-time-right delle scritture contabili. Dove trovare È un esito catturato dal log di SAP Business Workflow, che rappresenta una decisione di 'rifiuto' finale che termina il processo. Il documento può essere successivamente eliminato. Acquisisci Identificazione dello stato terminale di 'rifiuto' nel log del workflow per il documento. Tipo di evento inferred | |||
| Voce di registrazione contabile pareggiata | Questa attività rappresenta il pareggio di una voce di un conto CoGe a partite aperte. Avviene quando una voce viene abbinata a un'altra, chiudendola. | ||
| Perché è importante Per processi come la riconciliazione bancaria, il tempo necessario per compensare le voci è un KPI cruciale. Questa attività aiuta ad analizzare l'efficienza della riconciliazione e delle procedure di chiusura di fine mese. Dove trovare L'evento è acquisito dalla tabella delle voci BSEG. Quando una voce è pareggiata, vengono popolati i campi data di pareggio (BSEG-AUGDT) e documento di pareggio (BSEG-AUGBL). Il timestamp dell'evento è la data di pareggio. Acquisisci Identificazione di quando viene popolata la data di pareggio (BSEG-AUGDT) per una voce. Tipo di evento explicit | |||
Guide all'Estrazione
Fasi
- Creazione del programma ABAP: Nel sistema SAP, acceda alla transazione SE38 (ABAP Editor). Inserisca un nome per il nuovo programma (es. Z_PM_JE_EXTRACTION) e clicchi su "Crea". Fornisca un titolo adeguato e imposti il tipo di programma come 'Programma eseguibile'.
- Definizione della schermata di selezione: Nel codice sorgente del programma, definisca la schermata di selezione. Ciò consente agli utenti di specificare parametri come l'intervallo di date per la creazione del documento, le società e i tipi di documento per limitare il volume dei dati per l'estrazione.
- Dichiarazione delle strutture dati: Definisca una struttura di tabella interna che conterrà i dati finali dell'event log. Questa struttura deve includere tutti i campi richiesti: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate e qualsiasi attributo raccomandato come User, CompanyCode e PostingDate.
- Implementazione della logica di selezione dati: Scriva le query SQL ABAP principali per estrarre i dati per ciascuna delle 14 attività richieste. Ciò comporta la selezione di dati da tabelle primarie come BKPF (Testata) e BSEG (Posizione), tabelle di log delle modifiche CDHDR e CDPOS, tabelle di workflow come SWWLOGHIST e tabelle di compensazione come BSAS e BSAK.
- Estrazione di documenti in sospeso e contabilizzati: Per gli eventi 'Journal Entry Parked', selezioni da BKPF dove lo stato del documento (BSTAT) è 'V'. Per gli eventi 'Journal Entry Created' e 'Journal Entry Posted', selezioni da BKPF dove lo stato è vuoto, indicando un normale documento contabilizzato.
- Estrazione degli eventi di modifica e cancellazione: Interroghi le tabelle dei documenti di modifica, CDHDR e CDPOS, per la classe oggetto 'BELEG'. Filtri sulla chiave del documento per trovare le modifiche che corrispondono alle attività 'Journal Entry Corrected' o 'Parked Journal Entry Deleted'.
- Estrazione degli eventi del workflow: Per catturare attività come 'Journal Entry Submitted', 'Approved', 'Rejected' e 'Changes Requested', interroghi le tabelle del workflow. Utilizzi la tabella SWW_WI2OBJ per collegare il documento contabile a un'istanza di workflow, quindi legga SWWLOGHIST per le decisioni specifiche dell'utente o i cambi di stato.
- Identificazione degli eventi calcolati: Per 'Manual Entry Identified', controlli il codice transazione (BKPF-TCODE) rispetto a un elenco di codici transazione noti per le inserzioni manuali. Per 'Cross-Company Posting Identified', analizzi le posizioni BSEG per un dato documento per verificare se sono coinvolte più società.
- Consolidamento e trasformazione dei dati: Man mano che i dati di ogni attività vengono selezionati, li trasformi nella struttura finale dell'event log. Concateni Società, Numero documento ed Esercizio per creare il JournalEntryId. Converta le date e gli orari SAP in un unico timestamp EventTime. Aggiunga i risultati di ogni query alla tabella interna finale.
- Implementazione dell'esportazione dei file: Utilizzi le istruzioni ABAP per la gestione dei file, come OPEN DATASET, LOOP AT, TRANSFER e CLOSE DATASET, per scrivere la tabella interna consolidata su un file CSV o flat nella directory dell'application server SAP (visualizzabile tramite la transazione AL11).
- Pianificazione come job in background: Acceda alla transazione SM36 (Definizione job in background). Crei un nuovo job, definisca uno step che esegua il Suo programma ABAP e imposti una pianificazione (es. notturna o settimanale durante gli orari non di punta) per automatizzare l'estrazione.
- Recupero e formattazione del file: Utilizzi la transazione CG3Y o collabori con il Suo amministratore di sistema per scaricare il file generato dall'application server sul Suo computer locale. Si assicuri che la codifica e il formato del file siano adatti per l'upload nel Suo strumento di Process Mining.
Configurazione
- Intervallo di date: È fondamentale definire un intervallo di date per gestire le prestazioni. Utilizzi la data di creazione del documento (BKPF-CPUDT) come filtro principale. Per un'analisi iniziale, si consiglia un periodo di 3-6 mesi. Per i test, utilizzi un intervallo di pochi giorni in cui si sa che sono presenti dati.
- Filtro Società: Filtri sempre per società (BKPF-BUKRS). Estrarre dati per tutte le società contemporaneamente può richiedere un uso eccessivo di risorse. Inizi con una o un piccolo gruppo di società rilevanti.
- Filtro Tipo documento: Utilizzi il filtro per tipo documento (BKPF-BLART) per restringere l'ambito a specifiche tipologie di registrazioni contabili, come 'SA' per i documenti C/G, se non ha necessità di analizzare tutti i tipi di documento.
- ID Task del Workflow: La logica per l'estrazione degli eventi del workflow dipende dagli ID task specifici utilizzati nel Suo sistema per l'approvazione, il rifiuto e l'invio. Questi ID devono essere configurati nel codice sorgente del programma in base alle definizioni dei workflow della Sua azienda.
- Considerazioni sulle prestazioni: Il programma unisce diverse tabelle di grandi dimensioni, in particolare CDPOS e le tabelle dello storico dei workflow. L'esecuzione durante le ore di punta può influire sulle prestazioni del sistema. Lo pianifichi sempre come job in background da eseguire in orari non di punta. Valuti la creazione di indici di database secondari se le prestazioni sono un problema ricorrente.
- Prerequisiti: Questo metodo richiede un utente con autorizzazioni di sviluppo ABAP (per la transazione SE38) e permessi per creare e gestire job in background (per la transazione SM36). L'utente o il job necessitano inoltre dell'accesso in lettura a tutte le tabelle finanziarie, di sistema e di workflow pertinenti (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST, ecc.).
a Query di Esempio abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Fasi
- Stabilire la connessione al database: Ottenga le credenziali di sola lettura per il database SAP ECC. Utilizzi un client SQL standard, come DBeaver, SAP HANA Studio o SQL Server Management Studio, per connettersi al database.
- Preparare la query SQL: Copi la query SQL completa fornita nella sezione 'query' di questo documento nel Suo client SQL.
- Configurare i parametri di estrazione: Prima dell'esecuzione, deve configurare i segnaposto all'interno della query. Sostituisca
'[START_DATE]'e'[END_DATE]'con l'intervallo di date desiderato nel formato 'AAAAMMGG'. Sostituisca'[COMPANY_CODE_1]', '[COMPANY_CODE_2]'con i codici società SAP specifici che desidera analizzare. - Definire il sistema sorgente: Nell'istruzione
SELECTprincipale, sostituisca il segnaposto'[Your SAP System ID]'con l'ID di sistema SAP (SID) effettivo per identificare correttamente la sorgente dati. - Eseguire la query: Esegua la query SQL configurata sul database SAP. Il tempo di esecuzione varierà in base all'intervallo di date e alle dimensioni delle tabelle del database.
- Revisionare i risultati iniziali: Una volta completata la query, scansioni brevemente le righe restituite per assicurarsi che i dati siano popolati come previsto. Verifichi la presenza di varie attività e che i campi chiave come
JournalEntryIdeEventTimenon siano vuoti. - Gestire i timestamp: La query concatena i campi data e ora in una stringa
AAAAMMGGHHMMSS. Si assicuri che il Suo sistema di post-elaborazione o di destinazione possa analizzare questo formato, oppure adatti la funzione SQLCONCATa un formato ISO 8601 comeAAAA-MM-GGTHH:MI:SSse il database lo supporta. - Esportare i dati: Esporti l'intero set di risultati dal Suo client SQL in un file CSV. Si assicuri di utilizzare la codifica UTF-8 per evitare problemi con i caratteri speciali.
- Preparare per l'upload: Prima dell'upload nello strumento di Process Mining, confermi che le intestazioni delle colonne corrispondano allo schema dati richiesto.
JournalEntryId,ActivityNameedEventTimesono fondamentali. Aggiunga la colonnaLastDataUpdate, popolandola con il timestamp di esecuzione dell'estrazione. - Validazione finale: Esegua i passaggi descritti nella sezione 'validationSteps' per garantire che i dati estratti siano completi e accurati prima di iniziare l'analisi.
Configurazione
- Autorizzazioni database: L'utente del database richiede l'accesso in lettura alle seguenti tabelle SAP: BKPF, BSEG, CDHDR, CDPOS, T001 e V_USERNAME. Per le attività legate ai workflow, è necessario anche l'accesso a SWW_WI2OBJ e SWWLOGHIST. Questo livello di accesso viene solitamente concesso solo a team tecnici specializzati.
- Filtro per intervallo di date: È fondamentale filtrare i dati per un intervallo di date specifico per garantire le prestazioni della query. La query fornita utilizza dei segnaposto per la data di inizio e fine, applicati alla data di creazione del documento (
BKPF.CPUDT). Per un'analisi iniziale si consiglia un intervallo da 3 a 6 mesi. - Filtro per entità: Per gestire il volume dei dati e focalizzare l'analisi, filtri sempre per Società (
BKPF.BUKRS). Può anche considerare il filtraggio per Tipo documento (BKPF.BLART) per includere solo le tipologie di registrazioni contabili pertinenti (ad esempio 'SA' per i documenti C/G) ed escludere documenti operativi come fatture o pagamenti, se fuori ambito. - Considerazioni sulle prestazioni: Le query dirette su tabelle principali come BSEG e CDPOS possono richiedere molte risorse. Si consiglia vivamente di eseguire l'estrazione durante gli orari non lavorativi per evitare di impattare sulle prestazioni del sistema per gli utenti finali. Eviti di estrarre dati per più di un anno in un'unica esecuzione.
- ID Task del Workflow: La query contiene segnaposto come
'[WF_TASK_ID_SUBMIT]'e'[WF_TASK_ID_APPROVE]'. Questi devono essere sostituiti con gli ID task effettivi della configurazione specifica del workflow delle registrazioni contabili nel Suo sistema. Questi ID possono essere individuati collaborando con uno specialista SAP Workflow o analizzando la definizione tecnica del workflow nella transazione PFTC.
a Query di Esempio sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Fasi
- Stabilire la connessione SAP: Nel Suo strumento ETL di terze parti, configuri una nuova connessione sorgente al Suo sistema SAP ECC. Di solito sono necessari i dettagli dell'application server, il client, il numero di sistema e un utente SAP dedicato con le autorizzazioni RFC necessarie.
- Definire le sorgenti dati: All'interno del progetto di estrazione, aggiunga le tabelle SAP richieste come sorgenti dati. Le tabelle principali includono BKPF (Testata documento), BSEG (Posizione documento), VBSEGK (Testata documento in sospeso), CDHDR (Testata modifiche), CDPOS (Posizioni modifiche), SWW_WI2OBJ (Link Workflow-Oggetto), SWWLOGHIST (Log del Workflow) e SRGBTBREL (Relazioni per allegati GOS).
- Estrarre gli eventi di base (Creato e In sospeso): Crei il primo flusso di dati per estrarre gli eventi iniziali. Per 'Journal Entry Parked', utilizzi VBSEGK come sorgente. Per 'Journal Entry Created', utilizzi BKPF, assicurandosi di filtrare i documenti che non sono storni e che non sono stati inizialmente messi in sospeso (parked). Ciò può essere fatto tramite un anti-join con VBSEGK.
- Estrarre gli eventi del workflow: Crei un flusso di dati unendo BKPF a SWW_WI2OBJ utilizzando la chiave oggetto (società + numero documento + esercizio) per trovare l'ID istanza del workflow. Unisca questo risultato a SWWLOGHIST per estrarre eventi come 'Submitted', 'Approved', 'Rejected' e 'Changes Requested' in base agli esiti dei task e alle decisioni dell'utente registrate nel log.
- Estrarre gli eventi di modifica e cancellazione: Utilizzi le tabelle CDHDR e CDPOS per identificare le modifiche. Per 'Journal Entry Corrected', filtri le modifiche apportate ai documenti in sospeso (Classe oggetto 'FIPP'). Per 'Parked Journal Entry Deleted', cerchi i marcatori di cancellazione nei log delle modifiche per i documenti in sospeso.
- Estrarre gli eventi degli allegati: Per acquisire 'Documentation Attached', unisca BKPF a SRGBTBREL dove il tipo di oggetto è 'BKPF' e la relazione è '[Suo tipo di relazione allegato]'. La data di creazione del collegamento funge da EventTime.
- Estrarre gli eventi di compensazione e storno: Per 'Journal Entry Line Item Cleared', interroghi la tabella BSEG dove il campo del documento di compensazione (AUGBL) è popolato. L'EventTime è la data di contabilizzazione del documento di compensazione (AUGDT). Per 'Journal Entry Reversal Processed', interroghi BKPF per i documenti di storno, identificati dal valore nel campo del documento stornato (STBLG).
- Derivare gli eventi calcolati: Crei blocchi logici separati per gli eventi calcolati. Per 'Manual Entry Identified', filtri BKPF in base a un elenco di codici transazione manuali (es. FB01, FB50, F-02). Per 'Cross-Company Posting Identified', raggruppi la tabella BSEG per ID documento e identifichi i documenti con più di una società distinta.
- Combinare tutti i flussi di eventi: Utilizzi una trasformazione UNION nello strumento ETL per unire gli output di tutti i singoli flussi (Creato, In sospeso, Approvato, ecc.) in un'unica tabella di event log. Si assicuri che i nomi delle colonne e i tipi di dati siano coerenti.
- Mappare allo schema finale: Mappi i dati combinati alla struttura dell'event log richiesta, creando
JournalEntryId,ActivityName,EventTime,Usere altri attributi. Aggiunga colonne statiche comeSourceSysteme utilizzi l'ora di esecuzione del job ETL perLastDataUpdate. - Configurare il caricamento incrementale: Per le estrazioni continue, configuri una strategia di caricamento incrementale. Utilizzi l'ultima data di creazione o modifica (es. BKPF.CPUDT, CDHDR.UDATE) come watermark per estrarre solo i record nuovi o aggiornati dall'ultima esecuzione.
- Esportare per ProcessMind: Pianifichi il job di estrazione e configuri l'output finale per salvare l'event log come file CSV o Parquet in una posizione accessibile per l'upload.
Configurazione
- Prerequisiti: Uno strumento ETL di terze parti con licenza (es. Theobald Xtract Universal, Informatica, Talend) dotato di un connettore SAP dedicato. Un account utente SAP con accesso RFC e autorizzazioni per leggere le tabelle finanziarie (es. S_TABU_DIS per i gruppi di tabelle F_00, F_WF), i dati del workflow e i log delle modifiche.
- Parametri di connessione: Sono necessari l'IP o l'hostname dell'Application Server SAP, il numero del sistema e l'ID client. Per l'username e la password SAP è necessario utilizzare una gestione sicura delle credenziali.
- Filtri principali: Applichi sempre i filtri per Società (BKPF.BUKRS) ed Esercizio (BKPF.GJAHR) alla fonte per limitare il volume dei dati. Si consiglia vivamente di filtrare in base alla Data di creazione del documento (BKPF.CPUDT) per definire un periodo di estrazione specifico, ad esempio gli ultimi 6 mesi.
- Selezione dell'intervallo di date: Per il caricamento iniziale, selezioni un periodo rappresentativo come 3-6 mesi. Per i successivi caricamenti delta, utilizzi un watermark su un campo timestamp come
CPUDTper recuperare solo i nuovi record. - Considerazioni sulle prestazioni: I join su BSEG, CDPOS e sulle tabelle di workflow possono essere molto lenti. Si assicuri che lo strumento ETL applichi i filtri direttamente alla sorgente SAP (push down), ove possibile. Estragga i dati in piccoli pacchetti (chunk), specialmente per i grandi caricamenti storici.
- Personalizzazione del workflow: La logica per identificare le attività del workflow come 'Approvato' o 'Rifiutato' dipende fortemente dai Suoi specifici template di workflow. Dovrà identificare gli ID task del workflow e le chiavi decisionali dell'utente corretti dal Suo sistema per utilizzarli nei filtri.
a Query di Esempio config
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1