> Miglioramento continuo dei processi > Purchase to Pay Requisition > SAP ECC > Template dei dati

Il Suo Template dati per Purchase to Pay - Requisition

SAP ECC

Purchase to Pay - Requisition: attributi (19) Purchase to Pay - Requisition: attività (13) Guide all'estrazione (2)

Il Suo Template dati per Purchase to Pay - Requisition

Questo Template offre una guida completa alla raccolta dei dati essenziali necessari per analizzare il processo Purchase to Pay - Requisition. Indica i campi dati fondamentali da raccogliere, le attività chiave da monitorare e istruzioni pratiche per estrarre queste informazioni dal sistema di origine. Utilizzi questa risorsa per preparare i Suoi dati a un Process Mining efficace.

Attributi consigliati da raccogliere
Attività chiave da monitorare
Istruzioni 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

Purchase to Pay - Requisition: attributi

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del processo Purchase to Pay Requisition.

5 Obbligatorio 5 Consigliato 9 Facoltativo

	Nome	Descrizione
	ID della richiesta di acquisto PurchaseRequisitionId	L’identificativo univoco di un documento di richiesta di acquisto.
Descrizione L’ID della richiesta di 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 di acquisto o la chiusura. Nel Process Mining, questo ID è essenziale per ricostruire il ciclo di vita completo di ogni richiesta. Monitorando questo identificativo, gli analisti possono visualizzare l’intero flusso del processo, misurare la durata tra le diverse tappe e analizzare le variazioni nella gestione delle richieste. Consente di ottenere una visione coerente dell’intero percorso della richiesta. Perché è importante È l’identificativo principale che collega tutti gli eventi di processo correlati in un unico caso, rendendo possibile l’analisi end-to-end del processo. Dove reperirlo Si trova nella tabella EBAN, campo BANFN. Esempi 100234567810023456791002345680
	Nome dell’attività ActivityName	Il nome dell’attività aziendale che si è verificata in un determinato momento.
Descrizione Questo attributo descrive una fase o un evento specifico nel ciclo di vita della richiesta di acquisto, ad esempio «Richiesta di acquisto creata», «Approvazione inviata» o «Ordine di acquisto creato». Queste attività derivano generalmente da modifiche di stato, log del Workflow o documenti delle modifiche in SAP. L’analisi della sequenza e della frequenza delle attività costituisce il fondamento del Process Mining. Consente di individuare i flussi effettivi del processo, inclusi i percorsi più comuni, le deviazioni e i colli di bottiglia. È fondamentale per creare Dashboard come la Mappa del processo end-to-end delle richieste di acquisto e calcolare KPI relativi alla rielaborazione e alla Conformità. Perché è importante Definisce le fasi del processo, consentendo di visualizzare le mappe di processo e analizzare le variazioni del flusso. Dove reperirlo Derivato dalle tabelle dei documenti delle modifiche CDHDR e CDPOS, dai log del Workflow o da campi di stato come EBAN-STATU. Esempi Richiesta creataFase di approvazione approvataRichiesta rifiutataOrdine di acquisto creato
	Ora dell’evento EventTime	Il timestamp che indica quando si è verificata l’attività.
Descrizione Event Time registra la data e l’ora precise in cui si è svolta una specifica attività. Questo timestamp è fondamentale per tutte le analisi temporali nel Process Mining, inclusi il calcolo dei tempi di ciclo, l’identificazione dei colli di bottiglia e la valutazione delle prestazioni del processo. Nel contesto delle richieste di acquisto, questo attributo consente di calcolare KPI fondamentali come «Tempo medio di approvazione della richiesta di acquisto» e «Tempo di creazione dell’ordine di acquisto». Alimenta le Dashboard che visualizzano le durate, come l’analisi del tempo di ciclo dell’approvazione della richiesta di acquisto, fornendo i dati necessari per misurare il tempo tra due punti qualsiasi del processo. Perché è importante Questo timestamp è essenziale per calcolare tutte le durate, analizzare le prestazioni del processo e individuare i colli di bottiglia legati ai tempi. Dove reperirlo Si trova nella tabella di intestazione dei documenti delle modifiche CDHDR, nei 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 dal quale sono stati estratti i dati.
Descrizione Questo attributo specifica l’origine dei dati di processo, ad esempio «SAP ECC Production» o «S4HANA QA». Generalmente si tratta di un valore statico aggiunto durante l’estrazione dei dati per fornire il contesto necessario, soprattutto negli ambienti con più sistemi di origine. Nell’analisi dei processi, aiuta a distinguere i dati provenienti da fonti diverse, evitando che le analisi vengano distorte dalla combinazione di dati di produzione, test o sviluppo. È un elemento fondamentale dei metadati per la governance e la tracciabilità dei dati. Perché è importante Fornisce il contesto essenziale sull’origine dei dati, garantendo la tracciabilità e consentendo l’analisi di più sistemi. Dove reperirlo Si tratta di un valore statico generalmente 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	Il timestamp dell’aggiornamento o dell’estrazione più recente dei dati dal sistema di origine.
Descrizione Questo attributo indica quando il dataset è stato aggiornato l’ultima volta. È un timestamp statico applicato all’intero dataset durante ogni caricamento dei dati e funge da riferimento per valutarne l’aggiornamento. Per qualsiasi Dashboard o analisi di Process Mining, conoscere l’attualità dei dati è fondamentale per prendere decisioni informate. Questo attributo garantisce che tutti gli stakeholder siano consapevoli dell’intervallo temporale coperto dai dati visualizzati, evitando conclusioni basate su informazioni obsolete. Perché è importante Informa gli utenti sull’attualità dei dati, un elemento essenziale per la rilevanza e l’accuratezza dell’analisi del processo. Dove reperirlo Si tratta di un valore statico che rappresenta il timestamp 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 eseguito l’attività.
Descrizione Questo attributo identifica l’utente specifico responsabile di un evento, ad esempio della creazione di una richiesta di acquisto, dell’approvazione di una fase o della modifica di un documento. In SAP, viene spesso acquisito come ID utente. L’analisi per utente aiuta a individuare le esigenze formative, le prestazioni individuali e le potenziali fonti di errori di immissione dei dati. È essenziale per Dashboard come «Volumi di creazione delle richieste di acquisto per richiedente» e per comprendere la distribuzione del carico di lavoro e la Conformità alle policy di segregazione dei compiti. Perché è importante Attribuisce le attività a persone specifiche, consentendo di analizzare prestazioni, carico di lavoro, Conformità ed esigenze formative degli utenti. Dove reperirlo Si trova nella tabella di intestazione dei documenti delle modifiche CDHDR, nel campo USERNAME, per le modifiche, e in EBAN, nel campo ERNAM, per il creatore. 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. Generalmente deriva dal profilo utente del richiedente o dal centro di costo assegnato alla posizione 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 dell’approvazione della richiesta di acquisto» e del KPI «Variazione dei tempi di approvazione per reparto», che aiutano a individuare i reparti con processi efficienti e quelli che potrebbero richiedere miglioramenti o risorse aggiuntive. Perché è importante Consente di confrontare le prestazioni tra le unità aziendali, evidenziando i colli di bottiglia e le incoerenze di processo a livello di reparto. Dove reperirlo Spesso deriva dal collegamento tra il richiedente (EBAN-AFNAM) e i dati anagrafici degli utenti (SU01), oppure dall’utilizzo del centro di costo (EBKN-KOSTL) associato all’imputazione contabile della richiesta di acquisto. Esempi FinanzaOperations ITMarketingProduzione
	Stato della richiesta di acquisto RequisitionStatus	Lo stato di elaborazione corrente della richiesta di acquisto.
Descrizione Questo attributo indica lo stato complessivo della richiesta di acquisto in un determinato momento, ad esempio «In rilascio», «Approvata», «Rifiutata» o «Chiusa». In SAP è spesso rappresentato da un codice di stato. Il monitoraggio dello stato è essenziale per comprendere l’esito delle richieste di acquisto. Supporta direttamente la Dashboard «Esiti e tassi di rifiuto delle richieste di acquisto» e KPI come «Tasso di rifiuto delle richieste di acquisto» e «Tasso di ritiro delle richieste di acquisto». L’analisi delle transizioni tra gli stati aiuta a individuare inefficienze e punti di fallimento del processo. Perché è importante Definisce l’esito di una richiesta di acquisto, un elemento fondamentale per analizzare i tassi di successo, le motivazioni dei rifiuti e i punti finali del processo. Dove reperirlo Lo stato di elaborazione si trova nella tabella EBAN, campo STATU. Lo stato di rilascio 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	Una 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 complessivo seguito. Tra gli esempi rientrano «Richiesta di acquisto standard», «Trasferimento di stock» e «Richiesta di acquisto per servizi». Questo attributo è una dimensione particolarmente utile per l’analisi, poiché tipi di documento diversi seguono spesso 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’attività fondamentale per comprendere la Conformità e individuare opportunità di standardizzazione o specializzazione dei processi. Perché è importante Consente di segmentare le richieste di acquisto in diverse categorie di processo, rendendo l’analisi più precisa e pertinente. Dove reperirlo Si trova nella tabella EBAN, campo BSART. Esempi NBUBRV
	Valore totale della richiesta di acquisto TotalRequisitionValue	Il valore monetario complessivo di tutte le posizioni della richiesta di acquisto.
Descrizione Questo attributo rappresenta l’importo finanziario totale della richiesta di acquisto. Il valore è spesso un fattore determinante per stabilire il Workflow di approvazione necessario: le richieste di importo più elevato richiedono generalmente verifiche più approfondite e un numero maggiore di fasi di approvazione. L’analisi per valore è fondamentale per comprendere in che modo l’impatto finanziario influenzi il comportamento del processo. Può rivelare se le richieste di importo elevato richiedono più tempo per essere approvate, vengono rifiutate più spesso o seguono percorsi di processo diversi. È inoltre una metrica fondamentale per valutare il volume finanziario gestito dal processo di approvvigionamento. Perché è importante Aiuta a correlare il comportamento del processo con l’impatto finanziario, un elemento essenziale per l’analisi dei rischi e la comprensione della complessità delle approvazioni. Dove reperirlo Somma dei valori di tutte le posizioni. Il valore della posizione si trova nella tabella EBAN, campo GSWER. La valuta si trova in EBAN-WAERS. Esempi 1500.00250.50125000.00
	È rielaborazione IsRework	Un indicatore booleano che segnala se la richiesta di acquisto ha attraversato un ciclo di rielaborazione, ad esempio una modifica dopo l’invio.
Descrizione Si tratta di un attributo derivato che segnala le attività o i casi che comportano una rielaborazione. Ad esempio, qualsiasi attività «Richiesta di acquisto modificata» che si verifica dopo «Approvazione inviata» viene considerata rielaborazione. Può inoltre essere attivato da eventi di rifiuto che riportano il processo a una fase precedente. Questo indicatore è essenziale per la Dashboard «Analisi delle modifiche e della rielaborazione delle richieste di acquisto». Consente di filtrare e quantificare facilmente la rielaborazione, aiutando a misurarne l’impatto sui tempi di ciclo complessivi e a individuare le cause principali delle inefficienze di processo. Tassi elevati di rielaborazione indicano spesso problemi di qualità dei dati o requisiti poco chiari. Perché è importante Aiuta a quantificare la frequenza e l’impatto della rielaborazione, rendendo più semplice individuare e analizzare inefficienze e cicli del processo. Dove reperirlo Derivato dall’Event Log mediante l’identificazione di sequenze specifiche di attività, come «Richiesta di acquisto modificata» dopo un’attività di approvazione. Esempi truefalse
	Gruppo acquisti PurchasingGroup	Il gruppo di addetti agli acquisti responsabile dell’approvvigionamento degli articoli richiesti.
Descrizione Il Gruppo acquisti è un’unità organizzativa responsabile di specifiche attività di approvvigionamento. Rappresenta il team di addetti agli acquisti che gestirà la richiesta dopo la sua approvazione. Questo attributo è utile per analizzare il carico di lavoro e le prestazioni dei diversi team di acquisto. Può aiutare a individuare se determinati gruppi costituiscono colli di bottiglia nella conversione delle richieste in ordini di acquisto o se gestiscono alcuni tipi di richieste in modo più efficiente rispetto ad altri. Offre una dimensione fondamentale per la gestione delle risorse e delle prestazioni della funzione acquisti. Perché è importante Assegna la responsabilità dell’approvvigionamento, consentendo di analizzare il carico di lavoro e confrontare le prestazioni dei diversi team di acquisto. Dove reperirlo 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 utilizzata per raggruppare materiali o servizi con caratteristiche simili. Consente di analizzare le attività di approvvigionamento per categoria. L’analisi per gruppo merceologico supporta il sourcing strategico e l’analisi della spesa. Nel Process Mining può rivelare se le richieste relative a determinate categorie, come «Hardware IT» o «Servizi professionali», seguono percorsi di processo diversi o richiedono tempi di approvazione più lunghi. Questo insight è utile per il «Report sulla qualità dei dati delle richieste di acquisto» e per comprendere le variazioni del processo in base a ciò che viene acquistato. Perché è importante Consente di analizzare spesa e processo per categoria di approvvigionamento, supportando il sourcing strategico e l’identificazione dei colli di bottiglia specifici delle singole categorie. Dove reperirlo Si trova nella tabella EBAN, campo MATKL. Esempi 00101L001IT-SFTWR
	ID del fornitore VendorId	L’identificativo univoco del fornitore suggerito o fisso.
Descrizione Questo attributo contiene l’ID di un fornitore preferenziale o stabilito contrattualmente per l’articolo richiesto. 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 determinati fornitori sono associati a tassi di rifiuto più elevati. Offre una visione del coinvolgimento dei fornitori nelle prime fasi del processo. Perché è importante Fornisce insight sulle relazioni con i fornitori preferenziali e sul loro impatto sulla velocità e sugli esiti dell’elaborazione delle richieste di acquisto. Dove reperirlo 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 successivo creato per evaderla. In alcuni casi, una singola richiesta può generare più ordini di acquisto. Il collegamento è fondamentale per analizzare il passaggio tra il processo di richiesta e quello di acquisto. È necessario per calcolare il KPI «Tempo di creazione dell’ordine di acquisto dalla richiesta» e supportare la Dashboard «Ritardo tra richiesta approvata e creazione dell’ordine di acquisto». Comprendere questa relazione è essenziale per misurare l’efficienza dell’intero ciclo procure-to-pay. Perché è importante Collega il processo della richiesta di acquisto al processo di acquisto a valle, consentendo di analizzare i ritardi nel passaggio di consegne. Dove reperirlo Il numero dell’ordine di acquisto viene memorizzato nella tabella EBAN, campo EBELN, dopo la sua creazione. Esempi 450001712345000171244500017125
	Motivo del rifiuto RejectionReason	Il motivo indicato quando una richiesta di acquisto o una fase di approvazione viene rifiutata.
Descrizione Questo attributo registra la motivazione del rifiuto di una richiesta di acquisto. L’informazione viene generalmente inserita come testo libero oppure selezionata da un elenco predefinito di codici dall’approvatore durante l’attività di rifiuto. L’analisi dei motivi di rifiuto è fondamentale per il miglioramento del processo. Fornisce un riscontro diretto e operativo sulle cause del fallimento delle richieste, che possono includere violazioni delle policy, dati errati o budget non disponibile. Questi dati sono essenziali per la Dashboard «Esiti e tassi di rifiuto delle richieste di acquisto» e aiutano a individuare le cause principali delle inefficienze di processo. Perché è importante Fornisce insight diretti sui motivi per cui le richieste di acquisto vengono rifiutate, consentendo miglioramenti mirati del processo e della formazione degli utenti. Dove reperirlo Questi dati vengono generalmente memorizzati nei log del Workflow o nel testo esteso associato all’evento di rifiuto. Non esiste un campo standard in EBAN. Esempi Centro di costo erratoBudget superatoRichiesta duplicataNon conforme alla policy
	Nome del richiedente RequesterName	Il nome della persona che ha richiesto i beni o i servizi.
Descrizione Questo attributo identifica la persona che ha avviato la richiesta di acquisto, ossia colui o colei che ha l’esigenza aziendale relativa agli articoli richiesti. Il monitoraggio del richiedente consente di analizzare i modelli delle richieste per persona o gruppo. La Dashboard «Volumi di creazione delle richieste di acquisto per richiedente» utilizza questo attributo per individuare gli utenti più assidui, quelli che potrebbero necessitare di ulteriore formazione o i reparti con un’elevata attività di approvvigionamento. Offre una visione incentrata sulle persone del punto di avvio del processo. Perché è importante Identifica il responsabile del processo, consentendo di analizzare i modelli di creazione delle richieste di acquisto e di indirizzare in modo mirato la formazione degli utenti. Dove reperirlo Si trova nella tabella EBAN, campo AFNAM. Esempi Alice WilliamsBob JohnsonCharlie Brown
	Priorità Priority	Il livello di urgenza assegnato alla richiesta di acquisto.
Descrizione Questo attributo indica la priorità della richiesta di acquisto, spesso classificata come «Urgente», «Alta» o «Normale». L’indicatore segnala agli approvatori e agli addetti agli acquisti che la richiesta deve essere gestita con maggiore rapidità. È essenziale per la Dashboard «Prestazioni di elaborazione delle richieste urgenti» e per il KPI «Efficacia dell’indicatore di urgenza». L’analisi verifica se le richieste contrassegnate come urgenti vengono effettivamente elaborate più rapidamente di quelle standard, contribuendo a validare l’efficacia del sistema di prioritizzazione e a garantire che le esigenze aziendali critiche vengano soddisfatte tempestivamente. Perché è importante Consente di analizzare se le richieste urgenti vengono elaborate più rapidamente, verificando l’efficacia dei meccanismi di prioritizzazione. Dove reperirlo Non è un campo standard di EBAN. Viene spesso implementato come campo personalizzato oppure dedotto dal Numero di monitoraggio del fabbisogno (EBAN-BEDNR) o da uno specifico tipo di documento. Esempi 123
	Stabilimento Plant	La sede o lo stabilimento aziendale per il quale vengono richiesti i beni o i servizi.
Descrizione Lo Stabilimento è un’unità organizzativa dell’azienda e rappresenta una sede fisica, come una fabbrica, un magazzino o un ufficio. La richiesta di acquisto specifica lo stabilimento presso il quale sono necessari gli articoli richiesti. L’analisi per stabilimento consente di ottenere una visione geografica o specifica per sede del processo delle richieste di acquisto. Può evidenziare differenze di prestazioni tra le sedi, dovute a procedure locali, livelli di personale o esigenze aziendali differenti. È una dimensione comune per le Dashboard sulle prestazioni regionali. Perché è importante Fornisce un contesto geografico o basato sulla sede per l’analisi, aiutando a individuare variazioni del processo e differenze di prestazioni a livello regionale. Dove reperirlo Si trova nella tabella EBAN, campo WERKS. Esempi 10002100DE01

Obbligatorio Consigliato Facoltativo

Purchase to Pay - Requisition: attività

Questi sono i passaggi chiave e le principali tappe del processo da acquisire nell’Event Log per una corretta individuazione e analisi del Workflow delle richieste d’acquisto.

6 Consigliato 7 Facoltativo

	Attività	Descrizione
	Approvazione inviata	Questa attività indica che la richiesta è entrata nel Workflow formale di approvazione. In genere viene dedotta quando lo stato della richiesta cambia e richiede un'azione di rilascio o approvazione iniziale sulla base della strategia di rilascio configurata.
Perché è importante Questo evento segna l'inizio del tempo di ciclo di approvazione, un KPI fondamentale per misurare l'efficienza del processo. Comprendere questo punto aiuta a isolare i ritardi tra la creazione e l'avvio delle approvazioni formali. Dove reperirlo Deducibile 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 log del Workflow associati alla richiesta. Acquisizione Deducibile dalla prima voce del log delle modifiche che indica l'attivazione di una strategia di rilascio. Tipo di evento inferred
	Ordine di acquisto creato	Questa attività indica la conversione completata con successo di una richiesta di acquisto approvata in un documento d’ordine di acquisto. L’evento viene dedotto per la richiesta individuando una posizione d’ordine di acquisto corrispondente che vi fa riferimento.
Perché è importante In quanto principale esito positivo, questa attività conclude il processo della richiesta di acquisto e avvia la fase di approvvigionamento. Il tempo compreso tra «Richiesta di acquisto approvata» e questo evento è un KPI fondamentale per misurare l’efficienza del passaggio di consegne. Dove reperirlo Deducibile individuando un record nella tabella EKPO (posizione dell’ordine di acquisto) in cui i campi BANFN e BNFPO corrispondono al numero e alla posizione della richiesta di acquisto nella tabella EBAN. La data di creazione dell’ordine di acquisto (EKKO.AEDAT) fornisce il timestamp. Acquisizione Deducibile collegando le tabelle EBAN ed EKPO e utilizzando la data di creazione dell’ordine di acquisto proveniente da EKKO. Tipo di evento inferred
	Richiesta approvata	Questa attività rappresenta la tappa fondamentale in cui la Richiesta di acquisto ha superato correttamente tutti i passaggi di approvazione richiesti. L'evento viene dedotto quando viene applicato il release code finale e l'indicatore di rilascio complessivo (FRGZU) nella tabella EBAN viene impostato su uno stato approvato.
Perché è importante Questa è una tappa critica, 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 di acquisto. Dove reperirlo Deducibile dal timestamp della voce del log delle modifiche in CDPOS per la tabella EBAN e il campo FRGZU, quando il campo assume il valore che rappresenta l'approvazione finale. Acquisizione Deducibile dal campo dell'indicatore di rilascio finale in EBAN, quando raggiunge lo stato terminale "approvato". Tipo di evento inferred
	Richiesta creata	Questa attività indica la creazione e il salvataggio iniziali di una Richiesta di acquisto da parte di un utente. L'evento viene acquisito esplicitamente quando nella tabella EBAN viene generato un nuovo record, registrando la data e l'ora di creazione.
Perché è importante In quanto punto di partenza del processo, questa attività è essenziale per calcolare la durata complessiva del ciclo di vita della richiesta e analizzare il volume di creazione. Aiuta a identificare chi crea le richieste e quando. Dove reperirlo Questo 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 di acquisto (BANFN). Acquisizione Timestamp dei campi ERDAT e UZEIT della tabella EBAN al salvataggio iniziale del record. Tipo di evento explicit
	Richiesta di acquisto ritirata	Si tratta di un’attività terminale nella quale il creatore o un utente autorizzato annulla la posizione della richiesta di acquisto impostando un indicatore di cancellazione. L’azione viene registrata esplicitamente e indica che la necessità aziendale non è più valida oppure che la richiesta è stata creata per errore.
Perché è importante Si tratta di un punto di chiusura critico del processo, essenziale per calcolare il tasso di ritiro. Valori elevati possono indicare tempi di approvazione troppo lunghi, che inducono gli utenti ad abbandonare le richieste, oppure problemi sistemici nella pianificazione della domanda. Dove reperirlo Questa azione esplicita viene rilevata quando il campo «Deletion Indicator» (LOEKZ) nella tabella EBAN viene impostato per la posizione della richiesta di acquisto. La modifica viene registrata in CDHDR e CDPOS. Acquisizione Voce del registro delle modifiche quando il Deletion Indicator (EBAN-LOEKZ) viene impostato su «L». Tipo di evento explicit
	Richiesta rifiutata	Questa è un'attività terminale, in cui la Richiesta di acquisto viene rifiutata definitivamente e non può proseguire. L'evento viene dedotto quando l'indicatore di rilascio nella tabella EBAN viene impostato da un approvatore sullo stato finale di rifiuto.
Perché è importante Questa attività rappresenta un punto finale chiave del processo ed è fondamentale per calcolare il KPI del tasso di rifiuto delle Richieste di acquisto. Analizzare questi casi aiuta a comprendere le ragioni del mancato approvvigionamento e degli sprechi. Dove reperirlo Deducibile dal timestamp della voce del log delle modifiche in CDPOS per la tabella EBAN e il campo FRGZU, quando il campo assume il valore che rappresenta il rifiuto finale. Acquisizione Deducibile dal campo dell'indicatore di rilascio finale in EBAN, quando raggiunge lo stato terminale "rifiutato". Tipo di evento inferred
	Approvazione reimpostata	Indica che l'intero Workflow di approvazione della richiesta è stato reimpostato, spesso a causa di una modifica significativa. L'evento viene dedotto quando lo stato di rilascio viene cancellato dopo essere stato precedentemente attivo, costringendo il processo di approvazione a ripartire dall'inizio.
Perché è importante Le reimpostazioni dell'approvazione sono eventi di rilavorazione significativi, con un forte impatto sul tempo di ciclo. Identificarle mette in evidenza le inefficienze del processo e gli effetti a valle delle modifiche alle Richieste di acquisto sul Workflow. Dove reperirlo Deducibile dai log delle modifiche (CDHDR/CDPOS) relativi alla 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 Deducibile dai log delle modifiche che mostrano la cancellazione dei campi della strategia di rilascio. Tipo di evento inferred
	Fase di approvazione approvata	Rappresenta l'azione esplicita con cui un utente autorizzato approva un singolo passaggio della strategia di rilascio. L'azione viene registrata come modifica allo stato di rilascio della richiesta, avvicinandola all'approvazione finale.
Perché è importante Monitorare le singole approvazioni è necessario per misurare la durata di ogni passaggio e analizzare le prestazioni dei diversi approvatori. È fondamentale per comprendere la conformità del Workflow. Dove reperirlo Acquisito dai log delle modifiche (CDHDR/CDPOS) sui campi dello stato di rilascio della tabella EBAN. L'azione dell'approvatore tramite la transazione ME54N o un T-code analogo attiva questa modifica registrata. Acquisizione Voce del log delle modifiche creata quando un approvatore esegue una transazione di rilascio. Tipo di evento explicit
	Fase di approvazione avviata	Indica che la richiesta è ora in attesa dell'azione di uno specifico approvatore o gruppo di approvazione, come definito nella strategia di rilascio. L'evento viene dedotto quando lo stato della richiesta indica che è in attesa di uno specifico release code.
Perché è importante Questa attività consente un'analisi dettagliata di ogni singolo passaggio della catena di approvazione. Aiuta a individuare quali approvatori o fasi causano i ritardi più lunghi nel processo. Dove reperirlo Deducibile 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 Deducibile dalle modifiche di stato che indicano l'attivazione di un nuovo release code in attesa di approvazione. Tipo di evento inferred
	Fase di approvazione rifiutata	Un utente autorizzato ha rifiutato esplicitamente un singolo passaggio della strategia di rilascio, rimandando in genere la richiesta al creatore per una modifica. L'azione viene registrata come modifica allo stato di rilascio della richiesta.
Perché è importante I rifiuti sono una delle principali cause di rilavorazioni e ritardi nel processo. Analizzarne frequenza e cause aiuta a identificare incomprensioni sulle policy, problemi di qualità dei dati o passaggi di approvazione inefficienti. Dove reperirlo Acquisito dai log delle modifiche (CDHDR/CDPOS) sui campi dello stato di rilascio della tabella EBAN. Un'azione di rifiuto tramite la transazione ME54N o un sistema analogo attiva una modifica di stato corrispondente. Acquisizione Voce del log delle modifiche creata quando un approvatore esegue un'azione di rifiuto. Tipo di evento explicit
	Richiesta bloccata	Rappresenta un'azione esplicita per bloccare una posizione della Richiesta di acquisto, impedendone la conversione in un ordine di acquisto. Il blocco viene impostato tramite un indicatore specifico sulla posizione della richiesta.
Perché è importante Il blocco indica un potenziale problema o una sospensione temporanea del processo di approvvigionamento. Il monitoraggio di questi eventi aiuta a individuare i colli di bottiglia nei quali le richieste di acquisto vengono approvate, ma non vengono gestite tempestivamente. Dove reperirlo Rilevato in seguito a una modifica del campo «Blocking Indicator» (EBAKZ) nella tabella EBAN. La modifica viene registrata in CDHDR e CDPOS. Acquisizione Evento registrato nelle tabelle delle modifiche quando il campo EBAN-EBAKZ viene valorizzato. Tipo di evento explicit
	Richiesta di acquisto chiusa	Rappresenta la chiusura definitiva di una posizione della richiesta di acquisto e indica che non sono previste ulteriori elaborazioni. Questo stato viene dedotto quando la posizione è stata interamente convertita in un ordine di acquisto ed evasa, oppure quando è stata contrassegnata manualmente come chiusa.
Perché è importante Fornisce un punto finale definitivo per le richieste di acquisto completate, ma non necessariamente eliminate. Garantisce il calcolo accurato della durata del ciclo di vita delle richieste evase con successo. Dove reperirlo Deducibile dall’indicatore «Closed» (EBAKZ con valore «S» o altro valore configurato) nella tabella EBAN. Questo stato viene spesso impostato automaticamente dal sistema dopo la conversione completa in ordine di acquisto e la registrazione dell’entrata merci. Acquisizione Deducibile dalla modifica dello stato nel campo EBAN-EBAKZ a un valore «closed». Tipo di evento inferred
	Richiesta modificata	Rappresenta qualsiasi modifica apportata a una Richiesta di acquisto dopo la sua creazione iniziale, ad esempio la variazione di quantità, prezzo o materiale. Queste modifiche vengono registrate nelle tabelle dei log delle modifiche SAP, fornendo una traccia di audit dettagliata.
Perché è importante Monitorare le modifiche è fondamentale per identificare i cicli di rilavorazione e i problemi di qualità dei dati. Un'elevata frequenza di modifiche può indicare requisiti iniziali poco chiari o lacune nella formazione degli utenti, con conseguenti ritardi nel processo. Dove reperirlo Acquisito dalle tabelle dei log delle modifiche CDHDR (testata) e CDPOS (posizione), dove la classe oggetto è EINKBELEG e l'ID oggetto è il numero della Richiesta di acquisto. È possibile analizzare le modifiche apportate a campi specifici. Acquisizione Evento registrato nelle tabelle delle modifiche CDHDR e CDPOS per il documento della Richiesta di acquisto. Tipo di evento explicit

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da SAP ECC

Passaggi

Conceda l'accesso al database: prima di iniziare, si assicuri di disporre dell'accesso in sola lettura al database sottostante di SAP ECC. Sono necessarie credenziali specifiche (nome utente, password, host e porta) e si tratta di un livello di accesso non standard, che deve essere approvato dai team SAP Basis e sicurezza.
Identifichi lo schema SAP: si connetta al database con un client SQL standard, come DBeaver, Toad o SQL Developer. Dovrà identificare lo schema SAP corretto in cui sono archiviate le tabelle, generalmente denominato SAPSR3 o SAPR3.
Prepari la query SQL: utilizzi la query SQL completa fornita in questo documento. La query è progettata per estrarre tutte le attività e gli Attributi richiesti unendo le tabelle dei dati anagrafici e quelle del registro modifiche.
Imposti i parametri della query: individui i valori segnaposto nella query. Deve sostituirli con i requisiti specifici del Suo sistema e della Sua attività. I segnaposto principali includono '{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, le funzioni per creare le marche temporali, come TO_TIMESTAMP, o per manipolare le stringhe potrebbero richiedere piccoli adattamenti in base al database specifico, ad esempio Oracle, SQL Server, DB2 o HANA.
Esegua l'estrazione: esegua la query personalizzata nel Suo client SQL. Per grandi volumi di dati, è fortemente consigliato eseguire questa operazione negli orari di minore attività, per evitare di compromettere le prestazioni del sistema.
Esamini i risultati preliminari: al termine della query, controlli rapidamente che l'output contenga le colonne previste (PurchaseRequisitionId, ActivityName, EventTime ecc.) e che vengano restituite righe relative a diverse attività.
Esporti in CSV: esporti l'intero set di risultati dal Suo client SQL in un file CSV. Si assicuri 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 rappresentare l'Event Log in forma tabellare e ordinata.
Carichi in ProcessMind: carichi il file CSV finale nel Suo progetto ProcessMind per l'analisi e la visualizzazione.

Configurazione

Connessione al database: è necessaria una connessione diretta al database SAP ECC. Serviranno il nome host, la porta, il nome del database e 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 su un intervallo di date specifico. Consigliamo 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 per codice società (BUKRS) e tipo di documento della richiesta di 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 credenziali dirette al database. Non è un'attività standard per gli utenti finali.
Considerazioni sulle prestazioni: la query esegue join sulle tabelle del registro modifiche (CDHDR, CDPOS), che possono essere molto grandi. Senza filtri adeguati, la query potrebbe essere lenta e consumare risorse di sistema significative. La esegua sempre con un intervallo di date restrittivo e altri filtri.

a 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

Configurazione dell’ambiente Python: si assicuri di avere installato Python 3.6 o una versione successiva. Crei una cartella di 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 contenuti e collochi i file delle librerie, ad esempio sapnwrfc.dll su Windows e libsapnwrfc.so su Linux, in una directory accessibile dal percorso di sistema o dallo script Python.
Configurazione della connessione SAP: apra lo script Python fornito. Individui la sezione relativa ai parametri di connessione SAP e sostituisca i valori segnaposto (ashost, sysnr, client, Utente, passwd) con le credenziali effettive del sistema SAP. Si assicuri che l’utente disponga delle autorizzazioni necessarie per eseguire RFC e accedere alle tabelle.
Definizione dei parametri di estrazione: nello script, imposti le variabili date_from e date_to per definire l’intervallo temporale desiderato. È consigliabile iniziare con un periodo più breve, ad esempio un mese, per testare il processo di estrazione.
Esecuzione dello script Python: esegua lo script dal terminale utilizzando il comando python your_script_name.py. Lo script si connetterà a SAP tramite RFC, chiamerà RFC_READ_TABLE per ciascuna tabella necessaria, ovvero EBAN, EKKO, EKPO, CDHDR e CDPOS, e scaricherà i dati.
Recupero dei dati: lo script recupera i dati grezzi relativi a richieste di acquisto, ordini di acquisto e documenti di modifica. Utilizza criteri di filtraggio, 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 localmente tutte le trasformazioni. Elabora i dati grezzi delle tabelle per generare voci Event Log distinte per ciascuna delle 13 attività richieste, come “Requisition Created”, “Approval Step Approved” e “Purchase Order Created”.
Generazione dell’Event Log: lo script combina gli eventi generati da ciascuna tabella in un unico DataFrame. Calcola i timestamp degli eventi, mappa i nomi degli utenti e struttura i dati nel formato richiesto per ID del caso, attività e timestamp.
Mappatura degli attributi: gli attributi principali, come PurchaseRequisitionId, ActivityName, EventTime, Utente e TotalRequisitionValue, vengono mappati sulle rispettive colonne del DataFrame finale.
Esportazione in CSV: lo script salva l’Event Log finale in un file CSV denominato event_log_pr.csv nella stessa directory. Il file è formattato per il caricamento diretto in ProcessMind.
Revisione e caricamento: apra il file CSV generato per verificare la completezza e la correttezza dei dati. Dopo la convalida, potrà procedere al caricamento del file nel progetto ProcessMind.

Configurazione

Connessione SAP: lo script richiede i dati per una connessione RFC diretta al sistema SAP ECC, inclusi 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 presenti nello script. Per le esecuzioni iniziali e per gestire le prestazioni, si consiglia di estrarre un intervallo di dati compreso tra 3 e 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), mentre i documenti di modifica vengono filtrati per data (CDHDR-UDATE) e classe oggetto (CDHDR-OBJECTCLAS = 'BANF').
Librerie Python: lo script si basa su pyrfc per la connettività SAP e su pandas per la manipolazione dei dati. Si assicuri che queste librerie siano installate nel Suo ambiente Python.
Prestazioni: l'estrazione tramite RFC_READ_TABLE può essere lenta per volumi di dati molto elevati, poiché i dati vengono acquisiti in sequenza, una tabella alla volta. È consigliabile eseguire l'estrazione negli orari di minore attività per ridurre il carico sul sistema.
Tipi di documento: per impostazione predefinita, lo script estrae tutti i tipi di documento delle richieste di acquisto. Per restringere l'ambito, può aggiungere un filtro successivo all'estrazione nel DataFrame pandas basato sulla colonna BSART della tabella EBAN.

a 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 per iniziare?

Utilizzi questo Template per assicurarsi che i Suoi dati siano strutturati correttamente per il Process Mining e ottenere così informazioni preziose sul processo Purchase to Pay - Requisition. Inizi oggi il percorso verso l'ottimizzazione del processo.

Torna alla guida al miglioramento Scarica il Template

Sblocchi l'efficienza di P2P Requisition: inizi subito la prova

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

Inizi la prova gratuita

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

Il Suo Template dati per Purchase to Pay - Requisition

Il Suo Template dati per Purchase to Pay - Requisition

Purchase to Pay - Requisition: attributi

Purchase to Pay - Requisition: attività

Guide all'estrazione

Query SQL diretta sul database sottostante di SAP ECC

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza SAP RFC per l'estrazione delle tabelle

Passaggi

Configurazione

a Query di esempio python

Pronto per iniziare?

Sblocchi l'efficienza di P2P Requisition: inizi subito la prova

Il Suo Template dati per Purchase to Pay - Requisition

Il Suo Template dati per Purchase to Pay - Requisition

Purchase to Pay - Requisition: attributi

Purchase to Pay - Requisition: attività

Guide all'estrazione

Query SQL diretta sul database sottostante di SAP ECC

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza SAP RFC per l'estrazione delle tabelle

Passaggi

Configurazione

a Query di esempio python

Pronto per iniziare?

Sblocchi l'efficienza di P2P Requisition: inizi subito la prova

La Sua privacy è importante