> Miglioramento continuo dei processi > Dall’acquisto al pagamento: richiesta d’acquisto > SAP ECC > Template dei dati

Il template dei dati per Purchase to Pay - Requisition

SAP ECC

Attributi di Purchase to Pay - Requisition(19) Attività di Purchase to Pay - Requisition(13) Guide all’estrazione(2)

Il template dei dati per Purchase to Pay - Requisition

Questo template fornisce indicazioni complete su come raccogliere i dati essenziali per analizzare il processo Purchase to Pay - Requisition. Descrive i campi dati da acquisire, le attività chiave da monitorare e offre indicazioni pratiche per estrarre queste informazioni dal sistema di origine. Utilizzi questa risorsa per preparare i dati necessari a un’analisi efficace con il Process Mining.

Attributi consigliati da raccogliere
Attività chiave da monitorare
Indicazioni per l’estrazione da SAP ECC

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi di Purchase to Pay - Requisition

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il processo Purchase to Pay - Requisition.

5 Obbligatorio 5 Consigliato 9 Facoltativo

	Nome	Descrizione
	ID della richiesta d’acquisto PurchaseRequisitionId	Identificativo univoco di un documento di richiesta d’acquisto.
Descrizione L’ID della richiesta d’acquisto è la chiave primaria che identifica in modo univoco ogni richiesta di beni o servizi in SAP ECC. Funge da identificativo centrale del caso e collega tutte le attività e le modifiche relative a una specifica richiesta, dalla creazione alla risoluzione finale, ad esempio la conversione in un ordine d’acquisto o la chiusura. Nel Process Mining, questo ID è essenziale per ricostruire il ciclo di vita completo di ogni richiesta. Tracciandolo, gli analisti possono visualizzare l’intero flusso del processo, misurare la durata tra le tappe e analizzare le differenze nella gestione delle varie richieste. In questo modo ottengono una visione unitaria dell’intero percorso della richiesta. Perché è importante È l’identificativo principale che collega tutti gli eventi di processo correlati in un unico caso e rende possibile l’analisi del processo da un capo all’altro. Dove reperirli Si trova nella tabella EBAN, campo BANFN. Esempi 100234567810023456791002345680
	Nome dell’attività ActivityName	Nome dell’attività aziendale che si è verificata in un momento specifico.
Descrizione Questo attributo descrive un passaggio o un evento specifico nel ciclo di vita della richiesta d’acquisto, ad esempio «Richiesta d’acquisto creata», «Approvazione inviata» o «Ordine d’acquisto creato». In genere, queste attività vengono ricavate dalle modifiche di stato, dai registri del flusso di lavoro o dai documenti delle modifiche in SAP. Analizzare la sequenza e la frequenza delle attività è alla base del Process Mining. Consente di individuare i flussi effettivi del processo, compresi i percorsi più comuni, gli scostamenti e i colli di bottiglia. È fondamentale per creare Dashboard come la mappa del processo delle richieste da un capo all’altro e calcolare i KPI relativi alle rilavorazioni e alla conformità. Perché è importante Definisce i passaggi del processo e consente di visualizzare le mappe di processo e analizzare le variazioni del flusso. Dove reperirli Ricavato dalle tabelle dei documenti di modifica CDHDR e CDPOS, dai log del flusso di lavoro o da campi di stato come EBAN-STATU. Esempi Richiesta d’acquisto creataPassaggio di approvazione approvatoRichiesta d’acquisto rifiutataOrdine d’acquisto creato
	Ora dell’evento EventTime	Data e ora in cui si è verificata l’attività.
Descrizione L’ora dell’evento registra la data e l’ora esatte in cui si è svolta una determinata attività. Questo timestamp è fondamentale per tutte le analisi temporali di Process Mining, tra cui il calcolo dei tempi di ciclo, l’individuazione dei colli di bottiglia e la comprensione delle prestazioni del processo. Nel contesto delle richieste di acquisto, questo attributo consente di calcolare KPI importanti come «Tempo medio di approvazione della richiesta» e «Tempo necessario per creare l’ordine di acquisto». Alimenta le Dashboard che visualizzano le durate, come l’analisi del tempo di ciclo di approvazione delle richieste, fornendo i dati grezzi necessari per misurare il tempo che intercorre tra due punti qualsiasi del processo. Perché è importante Questo timestamp è indispensabile per calcolare tutte le durate, analizzare le prestazioni del processo e individuare i colli di bottiglia legati ai tempi. Dove reperirli Si trova nella tabella di intestazione dei documenti di modifica CDHDR (campi UDATE e UTIME). Esempi 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	Sistema di origine SourceSystem	Identifica il sistema di origine da cui sono stati estratti i dati.
Descrizione Questo attributo specifica l’origine dei dati del processo, ad esempio «SAP ECC Production» o «S4HANA QA». In genere è un valore statico aggiunto durante l’estrazione dei dati per fornire un contesto, soprattutto negli ambienti con più sistemi di origine. Nell’analisi dei processi, consente di distinguere i dati provenienti da fonti diverse e di evitare che i risultati siano alterati dalla combinazione di dati di ambienti di produzione, test o sviluppo. È un metadato fondamentale per la governance e la tracciabilità dei dati. Perché è importante Fornisce il contesto necessario sull’origine dei dati, ne garantisce la tracciabilità e consente l’analisi di più sistemi. Dove reperirli È un valore statico, in genere aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi SAP_ECC_PRODS4HANA_EU_100ECC_US_FINANCE
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati dal sistema di origine.
Descrizione Questo attributo indica quando è stato aggiornato il set di dati per l’ultima volta. È un timestamp statico applicato all’intero set di dati a ogni caricamento e funge da riferimento per valutarne l’attualità. Per prendere decisioni informate con una Dashboard o un’analisi di Process Mining, è fondamentale sapere quanto sono recenti i dati. Questo attributo permette a tutti gli interessati di conoscere il periodo coperto dai dati visualizzati, evitando conclusioni basate su informazioni non aggiornate. Perché è importante Indica quanto sono aggiornati i dati, un’informazione essenziale per garantire la pertinenza e l’accuratezza dell’analisi del processo. Dove reperirli È un valore statico che rappresenta la data e l’ora dell’estrazione dei dati, aggiunto durante il processo ETL. Esempi 2024-01-15T04:00:00Z2024-01-16T04:00:00Z
	Nome utente User	L’ID dell’utente che ha svolto l’attività.
Descrizione Questo attributo identifica l’utente responsabile di un evento, ad esempio la creazione di una richiesta, l’approvazione di una fase o la modifica di un documento. In SAP, il dato è spesso registrato come ID utente. L’analisi per utente aiuta a individuare esigenze formative, differenze nelle prestazioni individuali e possibili fonti di errori di inserimento. È essenziale per Dashboard come «Volume di richieste create per richiedente» e per comprendere la distribuzione del carico di lavoro e il rispetto delle regole di separazione dei compiti. Perché è importante Associa le attività a singole persone, consentendo di analizzare le prestazioni degli utenti, il carico di lavoro, la conformità e le esigenze formative. Dove reperirli Per le modifiche, si trova nella tabella di intestazione dei documenti di modifica CDHDR (campo USERNAME); per il creatore, nella tabella EBAN (campo ERNAM). Esempi SMITHJR.DOEUSER123
	Reparto Department	Il reparto del richiedente o il centro di costo associato alla richiesta di acquisto.
Descrizione Questo attributo rappresenta l’unità aziendale o il reparto che ha avviato la richiesta di acquisto. Spesso si ricava dal profilo utente del richiedente o dal centro di costo assegnato alla riga della richiesta. L’analisi del processo per reparto è fondamentale per comprendere le differenze di prestazioni all’interno dell’organizzazione. È la dimensione principale della Dashboard «Tempo di ciclo di approvazione delle richieste» e del KPI «Scostamento dei tempi di approvazione tra reparti»; aiuta a individuare i reparti con processi efficienti e quelli che potrebbero aver bisogno di miglioramenti o risorse aggiuntive. Perché è importante Consente di confrontare le prestazioni tra unità aziendali, mettendo in evidenza i colli di bottiglia e le incoerenze nei processi dei singoli reparti. Dove reperirli Spesso si ricava collegando il richiedente (EBAN-AFNAM) ai dati anagrafici degli utenti (SU01) oppure utilizzando il centro di costo (EBKN-KOSTL) associato all’imputazione contabile della richiesta. Esempi FinanzaOperazioni ITMarketingProduzione
	Stato della richiesta RequisitionStatus	Lo stato corrente di elaborazione della richiesta di acquisto.
Descrizione Questo attributo indica lo stato complessivo della richiesta in un determinato momento, ad esempio «In fase di approvazione», «Approvata», «Rifiutata» o «Chiusa». In SAP è spesso rappresentato da un codice di stato. Monitorare lo stato è essenziale per comprendere l’esito delle richieste. Questo dato alimenta direttamente la Dashboard «Esiti delle richieste e tassi di rifiuto» e KPI come «Tasso di rifiuto delle richieste» e «Tasso di ritiro delle richieste». Analizzare i passaggi da uno stato all’altro aiuta a individuare inefficienze e punti critici del processo. Perché è importante Definisce l’esito di una richiesta, un dato fondamentale per analizzare i tassi di successo, le ragioni dei rifiuti e le fasi conclusive del processo. Dove reperirli Lo stato di elaborazione si trova nella tabella EBAN, campo STATU. Lo stato di approvazione si trova in EBAN-FRGZU. Esempi N (Non modificata)B (Ordine di acquisto creato)A (Richiesta di offerta creata)K (Chiusa)
	Tipo di documento RequisitionDocumentType	Classificazione che determina il tipo e le caratteristiche della richiesta di acquisto.
Descrizione In SAP, il tipo di documento controlla diversi aspetti della richiesta di acquisto, tra cui l’intervallo di numerazione, la selezione dei campi e il processo di approvvigionamento seguito. Alcuni esempi sono «Richiesta standard», «Trasferimento di magazzino» e «Richiesta di servizi». Questo attributo è una dimensione di analisi utile, perché i diversi tipi di documento spesso seguono flussi di processo e requisiti di approvazione distinti. Consente agli analisti di segmentare i dati e confrontare le prestazioni dei diversi processi di richiesta, un passaggio importante per valutare la conformità e individuare opportunità di standardizzazione o specializzazione. Perché è importante Consente di suddividere le richieste in diverse categorie di processo, per ottenere analisi più precise e pertinenti. Dove reperirli Si trova nella tabella EBAN, campo BSART. Esempi NBUBRV
	Valore totale della richiesta TotalRequisitionValue	Valore monetario complessivo di tutte le voci della richiesta di acquisto.
Descrizione Questo attributo rappresenta l’importo complessivo della richiesta di acquisto. Il valore è spesso determinante per stabilire il flusso di approvazione necessario: le richieste di importo elevato, infatti, richiedono in genere verifiche più approfondite e più passaggi di approvazione. L’analisi per valore è fondamentale per capire in che modo l’impatto finanziario influisce sul processo. Può rivelare se le richieste di importo elevato richiedono più tempo per essere approvate, vengono rifiutate più spesso o seguono percorsi diversi. È inoltre una metrica essenziale per valutare il volume finanziario gestito dal processo di approvvigionamento. Perché è importante Aiuta a mettere in relazione il comportamento del processo con l’impatto finanziario, un aspetto essenziale per l’analisi del rischio e per comprendere la complessità delle approvazioni. Dove reperirli Somma dei valori di tutte le voci. Il valore della singola voce si trova nella tabella EBAN, campo GSWER. La valuta è indicata in EBAN-WAERS. Esempi 1500.00250.50125000.00
	È una rilavorazione IsRework	Indicatore booleano che segnala se la richiesta è stata sottoposta a un ciclo di rilavorazione, ad esempio una modifica dopo l’invio.
Descrizione È un attributo derivato che segnala le attività o i casi che comportano una rilavorazione. Ad esempio, un’attività «Richiesta modificata» che si verifica dopo «Approvazione inviata» viene considerata una rilavorazione. Anche gli eventi di rifiuto che riportano il processo a una fase precedente possono attivare questo indicatore. Questo indicatore è essenziale per la Dashboard «Analisi delle modifiche e delle rilavorazioni delle richieste». Consente di filtrare e quantificare facilmente le rilavorazioni, misurandone l’impatto sui tempi di ciclo complessivi e individuando le cause profonde delle inefficienze del processo. Un’elevata frequenza di rilavorazioni spesso segnala problemi nella qualità dei dati o requisiti poco chiari. Perché è importante Aiuta a quantificare la frequenza e l’impatto delle rilavorazioni, facilitando l’individuazione e l’analisi delle inefficienze e dei cicli del processo. Dove reperirli Ricavato dall’event log individuando sequenze specifiche di attività, ad esempio l’attività «Richiesta modificata» che si verifica dopo un’attività di approvazione. Esempi truefalse
	Gruppo acquisti PurchasingGroup	Il gruppo di acquirenti responsabile dell’approvvigionamento degli articoli richiesti.
Descrizione Il gruppo acquisti è un’unità organizzativa responsabile di specifiche attività di approvvigionamento. Rappresenta il team di acquirenti che gestisce la richiesta una volta approvata. Questo attributo è utile per analizzare il carico di lavoro e le prestazioni dei diversi team di acquisto. Aiuta a individuare eventuali gruppi che costituiscono un collo di bottiglia nella conversione delle richieste in ordini di acquisto o che gestiscono determinati tipi di richiesta con maggiore efficienza. È una dimensione importante per la gestione delle risorse e delle prestazioni nell’ambito degli acquisti. Perché è importante Assegna le responsabilità per gli acquisti e consente di analizzare il carico di lavoro e confrontare le prestazioni dei diversi team. Dove reperirli Si trova nella tabella EBAN, campo EKGRP. Esempi 001002P01
	Gruppo merceologico MaterialGroup	Il gruppo o la categoria a cui appartiene il materiale o il servizio richiesto.
Descrizione Il gruppo merceologico è una classificazione che raggruppa materiali o servizi con caratteristiche simili e consente di analizzare le attività di approvvigionamento per categoria. L’analisi per gruppo merceologico è utile per la gestione strategica degli acquisti e l’analisi della spesa. In Process Mining, può rivelare se le richieste di determinate categorie, come «Hardware IT» o «Servizi professionali», seguono percorsi diversi o richiedono tempi di approvazione più lunghi. Queste informazioni sono utili per il «Rapporto sulla qualità dei dati delle richieste» e aiutano a comprendere le variazioni del processo in base agli articoli acquistati. Perché è importante Consente di analizzare la spesa e i processi per categoria di approvvigionamento, supportando la gestione strategica degli acquisti e l’individuazione dei colli di bottiglia specifici per categoria. Dove reperirli Si trova nella tabella EBAN, campo MATKL. Esempi 00101L001IT-SFTWR
	ID del fornitore VendorId	Identificativo univoco del fornitore suggerito o prestabilito.
Descrizione Questo attributo contiene l’ID di un fornitore preferenziale o vincolato da contratto per l’articolo richiesto. Il dato può essere precompilato o suggerito dal richiedente. L’analisi delle richieste per fornitore aiuta a valutare l’impatto della preselezione dei fornitori sul processo di approvvigionamento. Ad esempio, può mostrare se le richieste con un fornitore specificato vengono approvate più rapidamente o se alcuni fornitori sono associati a tassi di rifiuto più elevati. Offre una prospettiva sul coinvolgimento dei fornitori nelle fasi iniziali. Perché è importante Fornisce informazioni sui rapporti con i fornitori preferenziali e sul loro impatto sui tempi e sugli esiti dell’elaborazione delle richieste. Dove reperirli Si trova nella tabella EBAN, campo LIFNR (fornitore fisso). Esempi 100030025V9876
	ID dell’ordine di acquisto PurchaseOrderId	L’ID dell’ordine di acquisto creato a partire dalla richiesta.
Descrizione Questo attributo collega una richiesta di acquisto all’ordine di acquisto creato successivamente per soddisfarla. In alcuni casi, da una singola richiesta possono derivare più ordini di acquisto. Questo collegamento è fondamentale per analizzare il passaggio dalla richiesta al processo di acquisto. Serve per calcolare il KPI «Tempo necessario per creare l’ordine di acquisto dalla richiesta» e alimenta la Dashboard «Ritardo tra l’approvazione della richiesta e la creazione dell’ordine di acquisto». Comprendere questo collegamento è essenziale per misurare l’efficienza dell’intero ciclo procure-to-pay. Perché è importante Collega il processo di richiesta a quello di acquisto, consentendo di analizzare i ritardi nel passaggio tra le due fasi. Dove reperirli Dopo la creazione, il numero dell’ordine di acquisto viene memorizzato nella tabella EBAN, campo EBELN. Esempi 450001712345000171244500017125
	Motivo del rifiuto RejectionReason	Il motivo indicato quando viene rifiutata una richiesta o una fase di approvazione.
Descrizione Questo attributo registra la motivazione del rifiuto di una richiesta di acquisto. In genere, durante l’attività di rifiuto, l’approvatore inserisce un testo libero oppure seleziona un codice da un elenco predefinito. Analizzare i motivi di rifiuto è fondamentale per migliorare il processo. Fornisce indicazioni concrete sulle ragioni per cui le richieste non vanno a buon fine, ad esempio violazioni delle regole, dati errati o budget insufficiente. Questi dati sono essenziali per la Dashboard «Esiti delle richieste e tassi di rifiuto» e aiutano a individuare le cause profonde delle inefficienze del processo. Perché è importante Fornisce indicazioni dirette sui motivi del rifiuto delle richieste e consente di pianificare interventi mirati per migliorare il processo e formare gli utenti. Dove reperirli Questi dati sono in genere memorizzati nei log del flusso di lavoro o nel testo esteso associato all’evento di rifiuto. La tabella EBAN non contiene un campo standard per questo dato. Esempi Centro di costo erratoBudget superatoRichiesta duplicataNon conforme alle regole
	Nome del richiedente RequesterName	Nome della persona che ha richiesto i beni o i servizi.
Descrizione Questo attributo identifica la persona che ha avviato la richiesta di acquisto, ovvero chi ha necessità aziendale dei beni richiesti. Monitorare il richiedente consente di analizzare le richieste per singola persona o gruppo. La Dashboard «Volume di richieste create per richiedente» utilizza questo attributo per individuare gli utenti più attivi, quelli che potrebbero aver bisogno di ulteriore formazione e i reparti con un’elevata attività di approvvigionamento. Offre una prospettiva del processo incentrata sulle persone che lo avviano. Perché è importante Identifica il responsabile del processo, consentendo di analizzare le modalità di creazione delle richieste e di pianificare la formazione degli utenti. Dove reperirli Si trova nella tabella EBAN, campo AFNAM. Esempi Alice WilliamsBob JohnsonCharlie Brown
	Priorità Priority	Livello di urgenza assegnato alla richiesta di acquisto.
Descrizione Questo attributo indica la priorità della richiesta, spesso classificata come «Urgente», «Alta» o «Normale». Il contrassegno segnala ad approvatori e acquirenti che la richiesta deve essere gestita con urgenza. Questo attributo è essenziale per la Dashboard «Prestazioni di elaborazione delle richieste urgenti» e per il KPI «Efficacia del contrassegno di urgenza». L’analisi verifica se le richieste contrassegnate come urgenti vengono effettivamente elaborate più rapidamente di quelle standard, aiutando a valutare l’efficacia del sistema di priorità e a soddisfare tempestivamente le esigenze aziendali critiche. Perché è importante Consente di verificare se le richieste urgenti vengono elaborate più rapidamente e di valutare l’efficacia dei meccanismi di assegnazione delle priorità. Dove reperirli Non è un campo standard della tabella EBAN. Spesso viene implementato come campo personalizzato oppure dedotto dal numero di tracciamento del fabbisogno (EBAN-BEDNR) o da un tipo di documento specifico. Esempi 123
	Stabilimento Plant	La sede aziendale o lo stabilimento per cui sono richiesti i beni o i servizi.
Descrizione Lo stabilimento è un’unità organizzativa dell’azienda che rappresenta una sede fisica, ad esempio una fabbrica, un magazzino o un ufficio. La richiesta specifica lo stabilimento in cui servono gli articoli richiesti. L’analisi per stabilimento offre una prospettiva geografica o legata alla sede sul processo di richiesta. Può mettere in evidenza differenze di prestazioni tra sedi, dovute a procedure locali, livelli di personale o esigenze aziendali diversi. È una dimensione utilizzata spesso nelle Dashboard sulle prestazioni regionali. Perché è importante Fornisce un contesto geografico o legato alla sede, aiutando a individuare variazioni del processo e differenze di prestazioni tra le diverse aree. Dove reperirli Si trova nella tabella EBAN, campo WERKS. Esempi 10002100DE01

Obbligatorio Consigliato Facoltativo

Attività di Purchase to Pay - Requisition

Questi sono i passaggi e le tappe fondamentali del processo da acquisire nell’Event Log per individuare e analizzare con precisione il flusso di lavoro delle richieste d’acquisto.

6 Consigliato 7 Facoltativo

	Attività	Descrizione
	Approvazione inviata	Questa attività indica che la richiesta è entrata nel flusso di lavoro formale di approvazione. In genere viene dedotta quando lo stato della richiesta cambia e richiede un primo rilascio o un’azione di approvazione in base alla strategia di rilascio configurata.
Perché è importante Questo evento segna l’inizio del tempo di ciclo dell’approvazione, un KPI fondamentale per misurare l’efficienza del processo. Individuare questo momento aiuta a isolare i ritardi tra la creazione della richiesta e l’avvio delle approvazioni formali. Dove reperirli Dedotto dalla prima modifica di stato relativa alla strategia di rilascio nella tabella EBAN, ad esempio quando il campo FRGZU passa dallo stato iniziale a uno stato in attesa, oppure dalla prima voce nei registri del flusso di lavoro associati alla richiesta. Acquisizione Dedotto dalla prima voce del registro delle modifiche che indica l’attivazione di una strategia di rilascio. Tipo di evento inferred
	Ordine d’acquisto creato	Questa attività indica la conversione corretta di una richiesta d’acquisto approvata in un documento d’ordine d’acquisto. L’evento viene dedotto per la richiesta individuando una posizione dell’ordine d’acquisto corrispondente che la richiama.
Perché è importante Essendo il principale esito positivo, questa attività conclude il processo della richiesta e avvia la fase di approvvigionamento. Il tempo che intercorre tra «Richiesta d’acquisto approvata» e questo evento è un KPI fondamentale per misurare l’efficienza del passaggio di consegne. Dove reperirli Dedotto individuando un record nella tabella EKPO (posizioni dell’ordine d’acquisto), in cui i campi BANFN e BNFPO corrispondono al numero e alla posizione della richiesta d’acquisto nella tabella EBAN. La data di creazione dell’ordine d’acquisto (EKKO.AEDAT) fornisce la data e l’ora dell’evento. Acquisizione Dedotto collegando le tabelle EBAN ed EKPO e utilizzando la data di creazione dell’ordine d’acquisto da EKKO. Tipo di evento inferred
	Richiesta d’acquisto approvata	Questa attività indica che la richiesta d’acquisto ha superato correttamente tutti i passaggi di approvazione previsti. L’evento viene dedotto quando viene applicato il codice di rilascio finale e l’indicatore di rilascio complessivo (FRGZU) nella tabella EBAN assume uno stato approvato.
Perché è importante È una tappa fondamentale, che segna la fine del ciclo di approvazione e l’inizio della fase di approvvigionamento. È essenziale per calcolare il KPI del tempo totale di approvazione e misurare i ritardi nel passaggio alla creazione dell’ordine d’acquisto. Dove reperirli Dedotto dalla data e dall’ora della voce del registro delle modifiche in CDPOS per la tabella EBAN, campo FRGZU, quando il valore passa a quello che indica l’approvazione finale. Acquisizione Dedotto quando il campo dell’indicatore di rilascio finale in EBAN raggiunge lo stato terminale «approvato». Tipo di evento inferred
	Richiesta d’acquisto creata	Questa attività indica la creazione iniziale e il salvataggio di una richiesta d’acquisto da parte di un utente. L’evento viene registrato esplicitamente quando viene creato un nuovo record nella tabella EBAN, con la data e l’ora di creazione.
Perché è importante Essendo il punto di partenza del processo, questa attività è essenziale per calcolare la durata complessiva del ciclo di vita della richiesta e analizzare il volume delle richieste create. Aiuta a individuare chi crea le richieste e quando. Dove reperirli L’evento viene acquisito dalla tabella EBAN utilizzando i campi della data di creazione (ERDAT) e dell’ora di creazione (UZEIT) per uno specifico ID della richiesta d’acquisto (BANFN). Acquisizione Data e ora ricavate dai campi ERDAT e UZEIT della tabella EBAN al primo salvataggio del record. Tipo di evento explicit
	Richiesta d’acquisto rifiutata	Questa è un’attività terminale: la richiesta d’acquisto viene rifiutata in via definitiva e non può proseguire. L’evento viene dedotto quando l’indicatore di rilascio nella tabella EBAN assume uno stato finale di rifiuto per decisione di un approvatore.
Perché è importante Questa attività è un punto finale importante del processo ed è fondamentale per calcolare il KPI del tasso di rifiuto delle richieste. Analizzare questi casi aiuta a comprendere le cause degli insuccessi e degli sprechi nell’approvvigionamento. Dove reperirli Dedotto dalla data e dall’ora della voce del registro delle modifiche in CDPOS per la tabella EBAN, campo FRGZU, quando il valore passa a quello che indica il rifiuto finale. Acquisizione Dedotto quando il campo dell’indicatore di rilascio finale in EBAN raggiunge lo stato terminale «rifiutato». Tipo di evento inferred
	Richiesta d’acquisto ritirata	Questa è un’attività terminale: il creatore o un utente autorizzato annulla la posizione della richiesta impostando un indicatore di cancellazione. L’azione viene registrata esplicitamente e indica che l’esigenza aziendale non è più valida o che la richiesta è stata creata per errore.
Perché è importante È un punto finale che segnala un insuccesso del processo ed è essenziale per calcolare il tasso di ritiro. Valori elevati possono indicare che i lunghi tempi di approvazione inducono gli utenti ad abbandonare le richieste oppure che esistono problemi sistemici nella pianificazione della domanda. Dove reperirli L’azione esplicita viene acquisita quando viene impostato il campo «Indicatore di cancellazione» (LOEKZ) della posizione della richiesta nella tabella EBAN. La modifica viene registrata in CDHDR e CDPOS. Acquisizione Voce del registro delle modifiche creata quando l’indicatore di cancellazione (EBAN-LOEKZ) viene impostato su «L». Tipo di evento explicit
	Approvazione reimpostata	Indica che l’intero flusso di lavoro di approvazione della richiesta è stato reimpostato, spesso a seguito di una modifica sostanziale. L’evento viene dedotto quando lo stato di rilascio viene azzerato dopo essere stato attivo, costringendo a riavviare il processo di approvazione dall’inizio.
Perché è importante Le reimpostazioni dell’approvazione sono eventi di rilavorazione significativi che incidono notevolmente sul tempo di ciclo. Individuarle mette in luce le inefficienze del processo e gli effetti a valle delle modifiche alle richieste sul flusso di lavoro. Dove reperirli Dedotto dai registri delle modifiche (CDHDR/CDPOS) della tabella EBAN, quando i campi dello stato di rilascio, come FRGZU, passano da uno stato in attesa o approvato a uno stato iniziale o vuoto. Acquisizione Dedotto dai registri delle modifiche che mostrano l’azzeramento dei campi della strategia di rilascio. Tipo di evento inferred
	Passaggio di approvazione approvato	Indica l’azione esplicita con cui un utente autorizzato approva un singolo passaggio della strategia di rilascio. L’azione viene registrata come modifica dello stato di rilascio della richiesta e la avvicina all’approvazione finale.
Perché è importante Monitorare le singole approvazioni è necessario per misurare la durata di ogni passaggio e analizzare i risultati dei diversi approvatori. È fondamentale per comprendere la conformità al flusso di lavoro. Dove reperirli Acquisito dai registri delle modifiche (CDHDR/CDPOS) relativi ai campi dello stato di rilascio della tabella EBAN. L’azione dell’approvatore tramite la transazione ME54N o un codice transazione simile genera la modifica registrata. Acquisizione Voce del registro delle modifiche creata quando un approvatore esegue una transazione di rilascio. Tipo di evento explicit
	Passaggio di approvazione avviato	Indica che la richiesta è in attesa dell’intervento di uno specifico approvatore o gruppo di approvazione, come previsto dalla strategia di rilascio. L’evento viene dedotto quando lo stato della richiesta indica che è in attesa di uno specifico codice di rilascio.
Perché è importante Questa attività consente di analizzare nel dettaglio ogni singolo passaggio della catena di approvazione. Aiuta a individuare gli approvatori o le fasi che causano i ritardi più lunghi. Dove reperirli Dedotto monitorando la sequenza delle modifiche ai campi dello stato di rilascio nella tabella EBAN. Ogni passaggio a un nuovo stato di attesa indica l’inizio di un nuovo passaggio di approvazione. Acquisizione Dedotto dalle modifiche di stato che indicano l’attivazione di un nuovo codice di rilascio in attesa di approvazione. Tipo di evento inferred
	Passaggio di approvazione rifiutato	Un utente autorizzato ha rifiutato esplicitamente un singolo passaggio della strategia di rilascio, rinviando in genere la richiesta al creatore perché la modifichi. L’azione viene registrata come modifica dello stato di rilascio della richiesta.
Perché è importante I rifiuti sono una delle principali cause di rilavorazioni e ritardi nel processo. Analizzarne la frequenza e le cause aiuta a individuare incomprensioni delle politiche, problemi di qualità dei dati o passaggi di approvazione inefficienti. Dove reperirli Acquisito dai registri delle modifiche (CDHDR/CDPOS) relativi ai campi dello stato di rilascio della tabella EBAN. Un rifiuto tramite la transazione ME54N o una transazione simile genera la corrispondente modifica di stato. Acquisizione Voce del registro delle modifiche creata quando un approvatore rifiuta la richiesta. Tipo di evento explicit
	Richiesta d’acquisto bloccata	Indica l’azione esplicita di bloccare una posizione della richiesta d’acquisto, impedendone la conversione in un ordine d’acquisto. Il blocco viene impostato tramite un indicatore specifico sulla posizione della richiesta.
Perché è importante Un blocco segnala un possibile problema o una sospensione temporanea dell’approvvigionamento. Monitorare questi eventi aiuta a individuare i colli di bottiglia in cui le richieste, pur essendo approvate, non vengono gestite subito. Dove reperirli Acquisito quando cambia il campo «Indicatore di blocco» (EBAKZ) nella tabella EBAN. La modifica viene registrata in CDHDR e CDPOS. Acquisizione Evento registrato nelle tabelle delle modifiche quando viene impostato il campo EBAN-EBAKZ. Tipo di evento explicit
	Richiesta d’acquisto chiusa	Indica la chiusura definitiva di una posizione della richiesta, dopo la quale non sono previste ulteriori elaborazioni. Lo stato viene dedotto quando la posizione è stata convertita completamente in un ordine d’acquisto e soddisfatta, oppure contrassegnata manualmente come chiusa.
Perché è importante Fornisce un punto finale certo per le richieste completate ma non necessariamente cancellate. Consente di calcolare con precisione la durata del ciclo di vita delle richieste soddisfatte. Dove reperirli Dedotto dall’indicatore «Chiuso» (EBAKZ con valore «S» o un altro valore configurato) nella tabella EBAN. Spesso il sistema imposta automaticamente questo stato quando la conversione in ordine d’acquisto e la ricezione della merce sono completate. Acquisizione Dedotto dalla modifica del campo EBAN-EBAKZ a un valore che indica la chiusura. Tipo di evento inferred
	Richiesta d’acquisto modificata	Indica qualsiasi modifica apportata a una richiesta d’acquisto dopo la creazione iniziale, ad esempio una variazione della quantità, del prezzo o del materiale. Queste modifiche vengono registrate nelle tabelle del registro delle modifiche di SAP, che forniscono una traccia di controllo dettagliata.
Perché è importante Monitorare le modifiche è fondamentale per individuare cicli di rilavorazione e problemi di qualità dei dati. Modifiche frequenti possono indicare requisiti iniziali poco chiari o lacune nella formazione degli utenti, con conseguenti ritardi nel processo. Dove reperirli L’evento viene acquisito dalle tabelle del registro delle modifiche CDHDR (testata) e CDPOS (posizione), quando la classe oggetto è EINKBELEG e l’ID oggetto corrisponde al numero della richiesta d’acquisto. È possibile analizzare le modifiche ai singoli campi. Acquisizione Evento registrato nelle tabelle delle modifiche CDHDR e CDPOS per il documento della richiesta d’acquisto. Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da SAP ECC

Passaggi

Ottenga l’accesso al database: prima di iniziare, verifichi di disporre dell’accesso in sola lettura al database sottostante di SAP ECC. Sono necessarie credenziali specifiche (nome utente, password, host e porta); si tratta di un livello di accesso non standard, che deve essere approvato dai team SAP Basis e sicurezza.
Individui lo schema SAP: si connetta al database con un client SQL standard, ad esempio DBeaver, Toad o SQL Developer. Dovrà individuare lo schema SAP corretto in cui sono archiviate le tabelle, che spesso si chiama SAPSR3 o SAPR3.
Prepari la query SQL: utilizzi la query SQL completa fornita in questo documento, progettata per estrarre tutte le attività e gli attributi richiesti unendo le tabelle dei dati anagrafici e quelle del registro delle modifiche.
Imposti i parametri della query: individui i valori segnaposto nella query e li sostituisca con quelli specifici del proprio sistema e dei requisiti aziendali. I segnaposto principali sono '{source_system_name}', '{start_date}', '{end_date}', '{company_codes}' e '{document_types}'.
Adatti la sintassi al database: la query fornita utilizza una sintassi SQL comune. Tuttavia, alcune funzioni per creare timestamp, come TO_TIMESTAMP, o per manipolare stringhe potrebbero richiedere piccoli adattamenti in base al database utilizzato, ad esempio Oracle, SQL Server, DB2 o HANA.
Esegua l’estrazione: esegua la query personalizzata nel client SQL. Per i set di dati di grandi dimensioni, è fortemente consigliato procedere nelle ore di minor carico, per evitare di incidere sulle prestazioni del sistema.
Controlli i risultati preliminari: al termine della query, verifichi rapidamente che l’output contenga le colonne previste (PurchaseRequisitionId, ActivityName, EventTime e così via) e che siano presenti righe relative a diverse attività.
Esporti i dati in CSV: esporti l’intero set di risultati dal client SQL in un file CSV. Verifichi che il file utilizzi la codifica UTF-8, per evitare problemi con i caratteri speciali.
Prepari il caricamento: verifichi che le intestazioni delle colonne CSV corrispondano esattamente agli alias definiti nella query SQL. Il file deve presentare i dati dell’Event Log in un formato tabellare ordinato.
Carichi il file in ProcessMind: carichi il file CSV finale nel progetto ProcessMind per analizzare e visualizzare i dati.

Configurazione

Connessione al database: è necessaria una connessione diretta al database SAP ECC. Occorrono il nome host, la porta, il nome del database e le credenziali utente appropriate.
Schema SAP: è necessario conoscere il nome dello schema che contiene le tabelle SAP, ad esempio SAPSR3. La query deve essere eseguita nel contesto di questo schema.
Intervallo di date: per gestire le prestazioni e il volume dei dati, è fondamentale applicare un filtro per un intervallo di date specifico. Si consiglia di iniziare con un periodo da 3 a 6 mesi. Imposti i segnaposto '{start_date}' e '{end_date}' nel formato YYYYMMDD.
Filtri organizzativi: per un’analisi più mirata, filtri i dati in base al codice società (BUKRS) e al tipo di documento della richiesta d’acquisto (BSART). Sostituisca i segnaposto '{company_codes}' e '{document_types}' con elenchi di valori separati da virgole, ad esempio '1000','2000'.
Prerequisiti: questo metodo richiede l’approvazione dei team SAP Basis e sicurezza per ottenere le credenziali di accesso diretto al database. Non è un’attività standard per gli utenti finali.
Considerazioni sulle prestazioni: la query unisce le tabelle del registro delle modifiche (CDHDR, CDPOS), che possono essere molto grandi. Senza filtri adeguati, l’esecuzione può essere lenta e consumare risorse significative del sistema. La esegua sempre con un intervallo di date ristretto e altri filtri.

Query di esempio sql

WITH REQUISITION_BASE AS (
    SELECT 
        EBAN.MANDT,
        EBAN.BANFN,
        EBAN.BNFPO,
        EBAN.BSART AS RequisitionDocumentType,
        EBAN.ERNAM,
        EBAN.ERDAT,
        EBAN.ERZET,
        EBAN.FRGZU AS CurrentRequisitionStatus,
        EBAKN.KOSTL AS Department,
        EBAKN.GSWRT
    FROM EBAN
    LEFT JOIN EBAKN ON EBAN.MANDT = EBAKN.MANDT AND EBAN.BANFN = EBAKN.BANFN AND EBAN.BNFPO = EBAKN.BNFPO
    WHERE EBAN.ERDAT BETWEEN '{start_date}' AND '{end_date}'
      AND EBAN.BUKRS IN ('{company_codes}')
      AND EBAN.BSART IN ('{document_types}')
),
REQUISITION_AGG AS (
    SELECT 
        MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department,
        SUM(GSWRT) AS TotalRequisitionValue
    FROM REQUISITION_BASE
    GROUP BY MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department
)
-- 1. Requisition Created
SELECT
    R.BANFN AS PurchaseRequisitionId,
    'Requisition Created' AS ActivityName,
    TO_TIMESTAMP(R.ERDAT || R.ERZET, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    R.ERNAM AS User,
    R.Department AS Department,
    R.CurrentRequisitionStatus AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM REQUISITION_AGG R

UNION ALL

-- 2. Requisition Amended, Approval Steps, Status Changes from Change Logs
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    CASE 
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW > C.VALUE_OLD THEN 'Approval Step Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW < C.VALUE_OLD THEN 'Approval Step Rejected'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_approval_status_code}' THEN 'Requisition Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_rejection_status_code}' THEN 'Requisition Rejected'
        WHEN C.FNAME = 'FRGSX' AND C.VALUE_OLD IS NOT NULL AND C.VALUE_NEW IS NULL THEN 'Approval Reset'
        WHEN C.FNAME = 'FRGZU' AND C.CHNGIND = 'U' AND C.TCODE LIKE 'ME54%' THEN 'Approval Submitted' 
        WHEN C.FNAME = 'LOEKZ' AND C.VALUE_NEW IN ('L', 'X') THEN 'Requisition Withdrawn'
        WHEN C.FNAME = 'EBAKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Blocked'
        WHEN C.FNAME = 'STATU' AND C.VALUE_NEW = 'B' THEN 'Purchase Order Created'
        WHEN C.FNAME = 'EREKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Closed'
        ELSE 'Requisition Amended'
    END AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    C.VALUE_NEW AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF'
  AND C.UDATE || C.UTIME <> R.ERDAT || R.ERZET -- Exclude changes made at the exact time of creation
  AND NOT (C.TCODE IN ('ME51', 'ME51N') AND C.UDATE = R.ERDAT) -- Exclude initial creation events from being amendments

UNION ALL

-- 3. Approval Step Started (Inferred)
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    'Approval Step Started' AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    P.VALUE_OLD AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF' AND P.FNAME = 'FRGZU' AND P.CHNGIND = 'U'
  AND P.VALUE_OLD IS NOT NULL AND P.VALUE_NEW IS NOT NULL AND P.VALUE_NEW > P.VALUE_OLD; -- This logic infers that a step starts just before it is approved

Passaggi

Configuri l’ambiente Python: verifichi di avere installato Python 3.6 o una versione successiva. Crei una cartella per il progetto e configuri un ambiente virtuale per gestire le dipendenze. Installi le librerie necessarie con pip: pip install pyrfc pandas numpy
SAP RFC SDK: scarichi SAP NetWeaver RFC SDK dal SAP Support Portal. Estragga i file e collochi le librerie (ad esempio, sapnwrfc.dll su Windows e libsapnwrfc.so su Linux) in una directory accessibile tramite il percorso di sistema o dallo script Python.
Configuri la connessione SAP: apra lo script Python fornito. Individui la sezione con i parametri di connessione SAP e sostituisca i valori segnaposto (ashost, sysnr, client, user, passwd) con le credenziali effettive del sistema SAP. Verifichi che l’Utente disponga delle autorizzazioni necessarie per eseguire chiamate RFC e accedere alle tabelle.
Definisca i parametri di estrazione: nello script, imposti le variabili date_from e date_to per definire l’intervallo di tempo desiderato per l’estrazione. Si consiglia di iniziare con un periodo più breve, ad esempio un mese, per verificare il processo.
Esegua lo script Python: esegua lo script dal terminale con il comando python your_script_name.py. Lo script si connetterà a SAP tramite RFC, chiamerà RFC_READ_TABLE per ogni tabella richiesta (EBAN, EKKO, EKPO, CDHDR, CDPOS) e scaricherà i dati.
Recupero dei dati: lo script recupera i dati grezzi relativi a richieste d’acquisto, ordini d’acquisto e documenti di modifica. Applica criteri di filtro, come intervalli di date e classi di oggetti, per limitare la quantità di dati trasferiti.
Trasformazione locale dei dati: una volta scaricati i dati, lo script utilizza la libreria pandas per eseguire tutte le trasformazioni localmente. Elabora i dati grezzi delle tabelle per generare voci distinte dell’Event Log per ciascuna delle 13 attività richieste, ad esempio «Richiesta creata», «Passaggio di approvazione approvato» e «Ordine d’acquisto creato».
Generi l’Event Log: lo script combina gli eventi generati da ciascuna tabella in un unico DataFrame. Calcola i timestamp degli eventi, associa i nomi degli utenti e struttura i dati nel formato richiesto per ID del caso, attività e timestamp.
Mappatura degli attributi: gli attributi chiave, come PurchaseRequisitionId, ActivityName, EventTime, User e TotalRequisitionValue, vengono associati alle rispettive colonne nel DataFrame finale.
Esporti i dati in CSV: lo script salva l’Event Log finale in un file CSV denominato event_log_pr.csv, nella stessa directory. Il file è pronto per essere caricato direttamente in ProcessMind.
Verifichi e carichi i dati: apra il file CSV generato e ne controlli la completezza e la correttezza. Una volta convalidato, può caricarlo nel progetto ProcessMind.

Configurazione

Connessione SAP: lo script richiede i dati per la connessione RFC diretta al sistema SAP ECC, tra cui server applicativo, numero di sistema, client, utente e password. L’utente specificato deve disporre delle autorizzazioni per le chiamate RFC e dell’accesso in visualizzazione alle tabelle EBAN, EKPO, EKKO, CDHDR e CDPOS.
Intervallo di date: l’estrazione è regolata dai parametri di data iniziale e finale definiti nello script. Per le prime esecuzioni e per gestire le prestazioni, si consiglia di estrarre dati relativi a un periodo da 3 a 6 mesi.
Filtri sulle tabelle: ove possibile, i filtri vengono applicati nelle chiamate RFC. Ad esempio, le richieste vengono filtrate per data di creazione (EBAN-ERDAT) e i documenti di modifica per data (CDHDR-UDATE) e classe di oggetti (CDHDR-OBJECTCLAS = 'BANF').
Librerie Python: lo script utilizza pyrfc per la connessione SAP e pandas per la manipolazione dei dati. Verifichi che queste librerie siano installate nell’ambiente Python.
Prestazioni: l’estrazione dei dati con RFC_READ_TABLE può essere lenta per set di dati molto grandi, poiché le tabelle vengono lette in sequenza. È consigliabile eseguire l’estrazione nelle ore di minor carico, per ridurre al minimo il carico sul sistema.
Tipi di documento: per impostazione predefinita, lo script estrae tutti i tipi di documento delle richieste d’acquisto. Per restringere l’ambito, può aggiungere un filtro dopo l’estrazione nel DataFrame pandas, basato sulla colonna BSART della tabella EBAN.

Query di esempio python

import pandas as pd
from pyrfc import Connection
import datetime

class=class="hl-string">"hl-comment"># --- 1. Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your SAP system connection details
SAP_CONNECTION_PARAMS = {
    class="hl-string">"ashost": class="hl-string">"your_sap_host",      class=class="hl-string">"hl-comment"># Application server host
    class="hl-string">"sysnr": class="hl-string">"00",                 class=class="hl-string">"hl-comment"># System number
    class="hl-string">"client": class="hl-string">"100",               class=class="hl-string">"hl-comment"># Client
    class="hl-string">"user": class="hl-string">"your_rfc_user",       class=class="hl-string">"hl-comment"># RFC user
    class="hl-string">"passwd": class="hl-string">"your_password"      class=class="hl-string">"hl-comment"># Password
}

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYYMMDD format)
date_from = class="hl-string">'20230101'
date_to = class="hl-string">'20231231'

source_system = class="hl-string">"SAP ECC"
last_data_update = datetime.datetime.now().isoformat()

class=class="hl-string">"hl-comment"># --- 2. Helper function for RFC_READ_TABLE ---
def rfc_read_table(conn, table_name, fields, options):
    class="hl-string">"""Fetches data from an SAP table using RFC_READ_TABLE."""
    try:
        result = conn.call(class="hl-string">'RFC_READ_TABLE',
                           QUERY_TABLE=table_name,
                           DELIMITER=class="hl-string">',',
                           FIELDS=fields,
                           OPTIONS=options)
        
        data = result[class="hl-string">'DATA']
        if not data:
            return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

        records = [row[class="hl-string">'WA'].strip().split(class="hl-string">',') for row in data]
        df = pd.DataFrame(records, columns=[field[class="hl-string">'FIELDNAME'] for field in fields])
        class=class="hl-string">"hl-comment"># Trim whitespace from all cells
        df = df.apply(lambda x: x.str.strip() if x.dtype == class="hl-string">"object" else x)
        return df
    except Exception as e:
        print(fclass="hl-string">"Error reading table {table_name}: {e}")
        return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

class=class="hl-string">"hl-comment"># --- 3. Main Extraction Logic ---
def main():
    print(class="hl-string">"Starting SAP data extraction...")
    try:
        conn = Connection(**SAP_CONNECTION_PARAMS)
    except Exception as e:
        print(fclass="hl-string">"Failed to connect to SAP: {e}")
        return

    class=class="hl-string">"hl-comment"># --- EBAN (Purchase Requisitions) ---
    print(class="hl-string">"Extracting EBAN...")
    eban_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'BSART'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERNAM'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERDAT'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERFZEIT'}, {class="hl-string">'FIELDNAME': class="hl-string">'PREIS'}, {class="hl-string">'FIELDNAME': class="hl-string">'MENGE'}, {class="hl-string">'FIELDNAME': class="hl-string">'KOSTL'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGZU'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGSX'}]
    eban_options = [fclass="hl-string">"ERDAT >= '{date_from}' AND ERDAT <= '{date_to}'"]
    df_eban = rfc_read_table(conn, class="hl-string">'EBAN', eban_fields, eban_options)
    if df_eban.empty:
        print(class="hl-string">"No requisitions found in EBAN for the given date range. Exiting.")
        conn.close()
        return

    df_eban[class="hl-string">'PREIS'] = pd.to_numeric(df_eban[class="hl-string">'PREIS'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'MENGE'] = pd.to_numeric(df_eban[class="hl-string">'MENGE'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'TotalRequisitionValue'] = df_eban[class="hl-string">'PREIS'] * df_eban[class="hl-string">'MENGE']
    df_eban_grouped = df_eban.groupby(class="hl-string">'BANFN').agg(
        TotalRequisitionValue=(class="hl-string">'TotalRequisitionValue', class="hl-string">'sum'),
        RequisitionDocumentType=(class="hl-string">'BSART', class="hl-string">'first'),
        Department=(class="hl-string">'KOSTL', class="hl-string">'first')
    ).reset_index()
    df_eban = df_eban.merge(df_eban_grouped, on=class="hl-string">'BANFN', suffixes=(class="hl-string">'', class="hl-string">'_agg'))

    class=class="hl-string">"hl-comment"># --- EKPO/EKKO (Purchase Orders) ---
    print(class="hl-string">"Extracting EKPO and EKKO...")
    banfn_list = class="hl-string">"'" + class="hl-string">"', '".join(df_eban[class="hl-string">'BANFN'].unique()) + class="hl-string">"'"
    ekpo_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}]
    ekpo_options = [fclass="hl-string">"BANFN IN ({banfn_list})"]
    df_ekpo = rfc_read_table(conn, class="hl-string">'EKPO', ekpo_fields, ekpo_options)

    ekko_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}, {class="hl-string">'FIELDNAME': class="hl-string">'AEDAT'}]
    if not df_ekpo.empty:
        ebeln_list = class="hl-string">"'" + class="hl-string">"', '".join(df_ekpo[class="hl-string">'EBELN'].unique()) + class="hl-string">"'"
        ekko_options = [fclass="hl-string">"EBELN IN ({ebeln_list})"]
        df_ekko = rfc_read_table(conn, class="hl-string">'EKKO', ekko_fields, ekko_options)
        df_po = pd.merge(df_ekpo, df_ekko, on=class="hl-string">'EBELN')
    else:
        df_po = pd.DataFrame(columns=[class="hl-string">'BANFN', class="hl-string">'BNFPO', class="hl-string">'EBELN', class="hl-string">'AEDAT'])

    class=class="hl-string">"hl-comment"># --- CDHDR/CDPOS (Change Documents) ---
    print(class="hl-string">"Extracting CDHDR and CDPOS...")
    cdhdr_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'OBJECTID'}, {class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'USERNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'UDATE'}, {class="hl-string">'FIELDNAME': class="hl-string">'UTIME'}]
    cdhdr_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND UDATE >= '{date_from}' AND UDATE <= '{date_to}'"]
    df_cdhdr = rfc_read_table(conn, class="hl-string">'CDHDR', cdhdr_fields, cdhdr_options)
    
    df_cdpos = pd.DataFrame()
    if not df_cdhdr.empty:
        class=class="hl-string">"hl-comment"># Process changenr in chunks to avoid overly long SQL queries
        changenr_chunks = [df_cdhdr[class="hl-string">'CHANGENR'][i:i + 100] for i in range(0, df_cdhdr.shape[0], 100)]
        cdpos_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'TABNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'FNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_NEW'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_OLD'}]
        cdpos_frames = []
        for chunk in changenr_chunks:
            changenr_list = class="hl-string">"'" + class="hl-string">"', '".join(chunk) + class="hl-string">"'"
            cdpos_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND CHANGENR IN ({changenr_list}) AND TABNAME = 'EBAN'"]
            cdpos_frames.append(rfc_read_table(conn, class="hl-string">'CDPOS', cdpos_fields, cdpos_options))
        if cdpos_frames:
            df_cdpos = pd.concat(cdpos_frames, ignore_index=True)

    conn.close()
    print(class="hl-string">"Extraction from SAP complete. Starting transformation...")

    class=class="hl-string">"hl-comment"># --- 4. Event Log Generation ---
    events = []

    class=class="hl-string">"hl-comment"># Activity: Requisition Created
    df_created = df_eban[[class="hl-string">'BANFN', class="hl-string">'ERNAM', class="hl-string">'ERDAT', class="hl-string">'ERFZEIT', class="hl-string">'RequisitionDocumentType', class="hl-string">'TotalRequisitionValue', class="hl-string">'Department']].drop_duplicates(subset=[class="hl-string">'BANFN'])
    for _, row in df_created.iterrows():
        events.append({
            class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': fclass="hl-string">"{row['ERDAT']} {row['ERFZEIT']}",
            class="hl-string">'User': row[class="hl-string">'ERNAM'],
            class="hl-string">'RequisitionDocumentType': row[class="hl-string">'RequisitionDocumentType'],
            class="hl-string">'TotalRequisitionValue': row[class="hl-string">'TotalRequisitionValue'],
            class="hl-string">'Department': row[class="hl-string">'Department'],
            class="hl-string">'RequisitionStatus': class="hl-string">'Created'
        })

    class=class="hl-string">"hl-comment"># Merge change documents
    df_changes = pd.DataFrame()
    if not df_cdhdr.empty and not df_cdpos.empty:
        df_changes = pd.merge(df_cdhdr, df_cdpos, on=class="hl-string">'CHANGENR')
        df_changes[class="hl-string">'PurchaseRequisitionId'] = df_changes[class="hl-string">'OBJECTID'].str[:10]
        df_changes[class="hl-string">'EventTime'] = pd.to_datetime(df_changes[class="hl-string">'UDATE'] + class="hl-string">' ' + df_changes[class="hl-string">'UTIME'], format=class="hl-string">'%Y%m%d %H%M%S')

    if not df_changes.empty:
        class=class="hl-string">"hl-comment"># Activities from Change Logs
        for _, row in df_changes.iterrows():
            activity = None
            status = None

            class=class="hl-string">"hl-comment"># Approval-related activities
            if row[class="hl-string">'FNAME'] in [class="hl-string">'FRGZU', class="hl-string">'FRGSX']:
                if row[class="hl-string">'VALUE_OLD'].strip() == class="hl-string">'' and row[class="hl-string">'VALUE_NEW'].strip() != class="hl-string">'':
                    activity = class="hl-string">'Approval Submitted'
                    status = class="hl-string">'In Approval'
                elif row[class="hl-string">'VALUE_OLD'] != class="hl-string">'' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'':
                    activity = class="hl-string">'Approval Reset'
                    status = class="hl-string">'In Progress'
                else:
                    class=class="hl-string">"hl-comment"># Logic to differentiate approve/reject might need config specifics
                    activity = class="hl-string">'Approval Step Approved' if row[class="hl-string">'VALUE_NEW'] > row[class="hl-string">'VALUE_OLD'] else class="hl-string">'Approval Step Rejected'
                    status = class="hl-string">'In Approval'
            class=class="hl-string">"hl-comment"># Final Approval/Rejection
            elif row[class="hl-string">'FNAME'] == class="hl-string">'FRGZU':
                 class=class="hl-string">"hl-comment"># This logic assumes specific final approval/rejection codes. Adjust if needed.
                 if row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'X', class="hl-string">'Y', class="hl-string">'Z']: class=class="hl-string">"hl-comment"># Placeholder for final approval states
                     activity = class="hl-string">'Requisition Approved'
                     status = class="hl-string">'Approved'
                 elif row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'R', class="hl-string">'S']: class=class="hl-string">"hl-comment"># Placeholder for final rejection states
                     activity = class="hl-string">'Requisition Rejected'
                     status = class="hl-string">'Rejected'
            class=class="hl-string">"hl-comment"># Other Amendments
            elif row[class="hl-string">'FNAME'] not in [class="hl-string">'FRGZU', class="hl-string">'FRGSX', class="hl-string">'LOEKZ', class="hl-string">'EBAKZ']:
                activity = class="hl-string">'Requisition Amended'
                status = class="hl-string">'Amended'
            class=class="hl-string">"hl-comment"># Blocked
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'B':
                activity = class="hl-string">'Requisition Blocked'
                status = class="hl-string">'Blocked'
            class=class="hl-string">"hl-comment"># Withdrawn
            elif row[class="hl-string">'FNAME'] == class="hl-string">'LOEKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Withdrawn'
                status = class="hl-string">'Withdrawn'
            class=class="hl-string">"hl-comment"># Closed
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Closed'
                status = class="hl-string">'Closed'

            if activity:
                events.append({
                    class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'PurchaseRequisitionId'],
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': row[class="hl-string">'EventTime'].strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'User': row[class="hl-string">'USERNAME'],
                    class="hl-string">'RequisitionStatus': status
                })

    class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
    if not df_po.empty:
        df_po_first = df_po.sort_values(class="hl-string">'AEDAT').drop_duplicates(class="hl-string">'BANFN', keep=class="hl-string">'first')
        for _, row in df_po_first.iterrows():
            events.append({
                class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': fclass="hl-string">"{row['AEDAT']} 00:00:00", class=class="hl-string">"hl-comment"># EKKO only has date
                class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User info not directly in EKKO/EKPO for this event
                class="hl-string">'RequisitionStatus': class="hl-string">'PO Created'
            })
            
    class=class="hl-string">"hl-comment"># Dummy activities for Approval Step Started (inferred before approval)
    class=class="hl-string">"hl-comment"># This is a simplified inference. Real logic can be much more complex.
    approval_events = [e for e in events if e[class="hl-string">'ActivityName'] == class="hl-string">'Approval Step Approved']
    for event in approval_events:
        event_time = pd.to_datetime(event[class="hl-string">'EventTime'])
        class=class="hl-string">"hl-comment"># Infer class="hl-string">'started' event one minute before class="hl-string">'approved' for demonstration
        start_time = event_time - datetime.timedelta(minutes=1)
        events.append({
            class="hl-string">'PurchaseRequisitionId': event[class="hl-string">'PurchaseRequisitionId'],
            class="hl-string">'ActivityName': class="hl-string">'Approval Step Started',
            class="hl-string">'EventTime': start_time.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
            class="hl-string">'User': None, class=class="hl-string">"hl-comment"># Approver user is not known until they approve
            class="hl-string">'RequisitionStatus': class="hl-string">'In Approval'
        })

    class=class="hl-string">"hl-comment"># --- 5. Final Formatting ---
    if not events:
        print(class="hl-string">"No events generated. Exiting.")
        return

    df_event_log = pd.DataFrame(events)
    df_event_log = df_event_log.merge(df_eban_grouped, left_on=class="hl-string">'PurchaseRequisitionId', right_on=class="hl-string">'BANFN', how=class="hl-string">'left')
    df_event_log[class="hl-string">'EventTime'] = pd.to_datetime(df_event_log[class="hl-string">'EventTime'])
    df_event_log = df_event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Fill forward attributes within each case
    df_event_log[class="hl-string">'RequisitionDocumentType'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'RequisitionDocumentType_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'TotalRequisitionValue'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'TotalRequisitionValue_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'Department'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'Department_agg'].transform(lambda x: x.ffill().bfill())

    class=class="hl-string">"hl-comment"># Add standard columns
    df_event_log[class="hl-string">'SourceSystem'] = source_system
    df_event_log[class="hl-string">'LastDataUpdate'] = last_data_update

    class=class="hl-string">"hl-comment"># Select and rename final columns
    final_columns = {
        class="hl-string">'PurchaseRequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName': class="hl-string">'ActivityName',
        class="hl-string">'EventTime': class="hl-string">'EventTime',
        class="hl-string">'SourceSystem': class="hl-string">'SourceSystem',
        class="hl-string">'LastDataUpdate': class="hl-string">'LastDataUpdate',
        class="hl-string">'User': class="hl-string">'User',
        class="hl-string">'Department': class="hl-string">'Department',
        class="hl-string">'RequisitionStatus': class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionDocumentType': class="hl-string">'RequisitionDocumentType',
        class="hl-string">'TotalRequisitionValue': class="hl-string">'TotalRequisitionValue'
    }
    df_event_log = df_event_log[final_columns.keys()].rename(columns=final_columns)
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df_event_log.to_csv(class="hl-string">'event_log_pr.csv', index=False)
    print(class="hl-string">"Event log successfully created: event_log_pr.csv")

if __name__ == class="hl-string">'__main__':
    main()

È pronto a iniziare?

Utilizzi questo template per strutturare correttamente i dati per il Process Mining e ottenere informazioni utili sul processo Purchase to Pay - Requisition. Inizi oggi il percorso di ottimizzazione del processo.

Torna alla guida al miglioramento

Scarica il template

Migliori l’efficienza delle richieste P2P: inizi subito la prova

Individui e risolva i colli di bottiglia P2P, riducendo il tempo di ciclo del 30% o più.

Inizi la prova gratuita

Non è richiesta la carta di credito; accesso gratuito per 14 giorni

Il template dei dati per Purchase to Pay - Requisition

Il template dei dati per Purchase to Pay - Requisition

Attributi di Purchase to Pay - Requisition

Attività di Purchase to Pay - Requisition

Guide all’estrazione

Query SQL diretta sul database sottostante di SAP ECC

Passaggi

Configurazione

Query di esempio sql

Script Python che utilizza SAP RFC per estrarre le tabelle

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Migliori l’efficienza delle richieste P2P: inizi subito la prova