> Miglioramento continuo dei processi > Purchase to Pay Requisition > SAP S/4HANA > Template dei dati

Il Suo Template di dati per Purchase to Pay - Requisition

SAP S/4HANA

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

Il Suo Template di dati per Purchase to Pay - Requisition

Questo template fornisce indicazioni complete per raccogliere i dati necessari all’analisi del processo Purchase to Pay - Requisition. Descrive gli attributi e le attività essenziali da monitorare e offre istruzioni pratiche per l’estrazione dei dati da SAP S/4HANA. Utilizzi questa risorsa per creare un Event Log affidabile e ottenere informazioni utili con il Process Mining.

Attributi consigliati da raccogliere per un’analisi dettagliata
Attività chiave da monitorare per l’individuazione dei processi
Indicazioni per estrarre i dati da SAP S/4HANA

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 un’analisi completa del processo Purchase to Pay - Requisition.

3 Obbligatorio 6 Consigliato 11 Facoltativo

	Nome	Descrizione
	ID della richiesta d’acquisto PurchaseRequisitionId	Identificativo univoco del 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 S/4HANA. Funge da identificativo centrale del caso e collega tutte le attività e le modifiche relative a una specifica richiesta, dalla creazione allo stato finale, ad esempio approvazione, rifiuto o conversione in ordine d’acquisto. Nel Process Mining, questo attributo è fondamentale per ricostruire il ciclo di vita end-to-end di ogni richiesta. Raggruppando tutti gli eventi correlati sotto un unico ID della richiesta d’acquisto, gli analisti possono misurare con precisione i tempi di ciclo, monitorare le modifiche di stato e analizzare i diversi percorsi che una richiesta può seguire durante l’approvazione. Perché è importante È l’identificativo essenziale del caso, che collega tutte le fasi di processo correlate e consente di ottenere una visione completa e coerente del ciclo di vita della richiesta. Dove reperirli È il numero della richiesta d’acquisto, presente nella tabella EBAN, campo BANFN. Esempi 100178901001789110017892
	Nome dell’attività ActivityName	Il nome dell’attività aziendale svolta in un determinato momento del processo di richiesta d’acquisto.
Descrizione Il nome dell’attività descrive un evento o un’operazione specifica che si è verificata nel ciclo di vita di una richiesta d’acquisto. Le attività vengono ricavate dai registri di sistema, ad esempio dai documenti di modifica e dalla cronologia del flusso di lavoro, e rappresentano tappe importanti del processo, come «Richiesta d’acquisto creata», «Fase di approvazione avviata» o «Ordine d’acquisto creato». Analizzare queste attività consente di visualizzare il flusso del processo, individuare i colli di bottiglia e misurare il tempo trascorso nelle diverse fasi. Comprendere la sequenza e la frequenza di attività come «Richiesta d’acquisto modificata» o «Richiesta d’acquisto respinta» è fondamentale per individuare inefficienze e opportunità di miglioramento. Perché è importante Definisce le fasi del processo, costituisce la struttura di base della mappa del processo e consente di analizzare il flusso, le varianti e i colli di bottiglia. Dove reperirli È un attributo derivato, in genere ottenuto interpretando i dati delle tabelle dei documenti di modifica (CDHDR, CDPOS) e dei registri del flusso di lavoro (ad es. SWWLOGHIST). Esempi Richiesta d’acquisto creataFase di approvazione completataRichiesta d’acquisto approvataOrdine d’acquisto creato
	Ora dell’evento EventTime	La data e l’ora esatte in cui si è verificata una specifica attività.
Descrizione L’ora dell’evento è la data e l’ora che registrano quando si è svolta un’attività. Questi dati sono fondamentali per ordinare cronologicamente gli eventi all’interno di un caso e costituiscono la base per tutti i calcoli di durata e prestazioni nel Process Mining. Ad esempio, la differenza tra l’evento «Richiesta d’acquisto inviata» e «Richiesta d’acquisto approvata» determina il tempo di ciclo di approvazione. Le date e le ore precise sono essenziali per analizzare le prestazioni del processo, individuare i ritardi e monitorare il rispetto degli accordi sui livelli di servizio. Questo attributo consente di creare Dashboard che visualizzano i tempi di ciclo, monitorano le richieste bloccate e confrontano le prestazioni in periodi diversi. Perché è importante Questa data e ora sono essenziali per ordinare gli eventi, calcolare i tempi di ciclo e analizzare le prestazioni del processo e i colli di bottiglia. Dove reperirli Le date e le ore provengono in genere dalle intestazioni dei documenti di modifica (CDHDR-UDATE, CDHDR-UTIME) o dai registri degli eventi del flusso di lavoro. Esempi 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z
	ID approvatore ApproverId	Identificativo dell’utente che ha approvato o respinto una richiesta.
Descrizione L’ID approvatore identifica specificamente l’utente che ha completato un’attività di approvazione o rifiuto. A differenza dell’ID utente generico, riguarda esclusivamente chi prende decisioni nel flusso di lavoro di approvazione. Registrare questa informazione è essenziale per analizzare nel dettaglio il processo di approvazione. Questo attributo consente di analizzare il comportamento degli approvatori, ad esempio individuando i responsabili che impiegano molto tempo ad approvare o che respingono spesso le richieste. È fondamentale per le Dashboard dedicate ai tempi di ciclo delle fasi di approvazione e all’analisi dei colli di bottiglia nel flusso di lavoro, poiché aiuta a individuare le persone o i ruoli che possono causare ritardi. Perché è importante Individua chi prende la decisione in una specifica fase di approvazione e consente di analizzare nel dettaglio i tempi di ciclo e i colli di bottiglia per persona o ruolo. Dove reperirli Queste informazioni vengono in genere estratte da tabelle SAP Business Workflow come SWW_WI2OBJ e SWWLOGHIST, che collegano le attività di lavoro all’utente che le ha completate. Esempi MJOHNSONCWILLIAMSLBLACK
	ID utente UserId	Identificativo dell’utente che ha creato la richiesta o svolto una specifica attività.
Descrizione L’ID utente identifica il dipendente o l’utente di sistema responsabile di un determinato evento nel ciclo di vita della richiesta. Può trattarsi della persona che ha creato la richiesta, del responsabile che l’ha approvata o dell’addetto che l’ha modificata. Nel caso di fasi automatizzate, può corrispondere all’ID di un utente di sistema o di elaborazione in batch. L’analisi per ID utente aiuta a comprendere i comportamenti dei singoli utenti, la distribuzione del carico di lavoro e le prestazioni. È utile per individuare esigenze di formazione, riconoscere le persone con i risultati migliori e garantire responsabilità chiare nel processo. Se combinata con i dati anagrafici degli utenti, consente anche di analizzare le prestazioni dei reparti. Perché è importante Consente di analizzare le prestazioni degli utenti, la distribuzione del carico di lavoro e la conformità del processo. È fondamentale per individuare opportunità di formazione e colli di bottiglia nell’impiego delle risorse. Dove reperirli Per il creatore, si trova in EBAN-ERNAM. Per le modifiche successive, è in CDHDR-USERNAME. Per le approvazioni, si trova nei registri del flusso di lavoro. Esempi JSMITHRROEWF-BATCH
	Importo della richiesta d’acquisto RequisitionAmount	Valore monetario totale della richiesta d’acquisto.
Descrizione L’importo della richiesta d’acquisto rappresenta il costo totale stimato dei beni o servizi richiesti. Spesso è un fattore determinante per la complessità e la durata del flusso di lavoro di approvazione: le richieste di importo elevato richiedono in genere più livelli di approvazione. Analizzare questo attributo consente di segmentare il processo in base al valore. Aiuta a rispondere a domande come «Le richieste di importo elevato richiedono più tempo per essere approvate?» oppure «Qual è il valore delle richieste che vengono respinte più spesso?». È una dimensione fondamentale per comprendere l’impatto finanziario delle inefficienze di processo. Perché è importante Consente di segmentare il processo in base all’impatto finanziario, spesso correlato alla complessità dell’approvazione e ai tempi di ciclo. È essenziale per analizzare il processo in funzione del valore. Dove reperirli Il valore totale si trova nella tabella EBAN, campo GFWERT. Il valore a livello di posizione è in EBAN-PREIS. Esempi 1500.0075000.50250.75
	Reparto Department	Il reparto o centro di costo a cui vengono addebitati i costi della richiesta.
Descrizione L’attributo Reparto, spesso rappresentato in SAP dal centro di costo, identifica l’unità aziendale responsabile dell’acquisto richiesto. È un’informazione finanziaria e organizzativa fondamentale, assegnata a livello di posizione della richiesta. Nel Process Mining, questo attributo è essenziale per analizzare le prestazioni dei reparti. Consente di creare Dashboard che confrontano metriche chiave, come i tempi di ciclo, la frequenza delle modifiche e quella dei rifiuti, tra reparti diversi. In questo modo è possibile individuare i reparti con i risultati migliori, le cui pratiche possono essere adottate altrove, e quelli che potrebbero aver bisogno di ulteriore formazione o supporto sul processo. Perché è importante Consente di confrontare le prestazioni tra unità aziendali, mettendo in evidenza le differenze nei tempi di ciclo o nei tassi di rifiuto per individuare le buone pratiche e le aree da migliorare. Dove reperirli È il centro di costo, generalmente presente nella tabella di assegnazione contabile EBKN, campo KOSTL. Esempi FIN-1001IT-2005MKT-3010
	Stato della richiesta d’acquisto RequisitionStatus	Stato attuale di elaborazione o approvazione della richiesta d’acquisto.
Descrizione Lo stato della richiesta d’acquisto indica la fase corrente del suo ciclo di vita. In SAP è spesso rappresentato dall’indicatore di rilascio, che segnala se la richiesta è bloccata, in approvazione, approvata parzialmente o approvata completamente. Lo stato cambia man mano che la richiesta avanza nel flusso di lavoro. Monitorare lo stato nel tempo è fondamentale per comprendere il flusso del processo e individuare dove e per quanto tempo le richieste rimangono bloccate. Analizzare i passaggi da uno stato all’altro consente di esaminare nel dettaglio il processo di approvazione e le sue varianti. Perché è importante Indica la fase corrente di una richiesta ed è fondamentale per monitorarne l’avanzamento, individuare i colli di bottiglia e analizzare il flusso del processo. Dove reperirli Lo stato di rilascio è spesso determinato dall’indicatore di rilascio, presente nella tabella EBAN, campo FRGZU. Esempi B1S
	Tipo di richiesta d’acquisto RequisitionType	Codice che classifica la richiesta d’acquisto, ad esempio per articoli standard, servizi o spese in conto capitale.
Descrizione Il tipo di richiesta d’acquisto, noto in SAP anche come tipo di documento, è un campo di configurazione importante che classifica le richieste d’acquisto. Tipi diversi possono attivare flussi di lavoro di approvazione differenti, prevedere impostazioni specifiche per i campi e rispondere a diverse esigenze aziendali, ad esempio per articoli di magazzino standard, servizi esterni o acquisti di cespiti. Analizzare il processo in base al tipo di richiesta d’acquisto consente alle organizzazioni di capire come vengono gestite le diverse richieste. È possibile confrontare prestazioni, tempi di ciclo e percorsi di approvazione tra le varie categorie, individuando i tipi di richiesta più o meno efficienti e definendo interventi di miglioramento mirati. Perché è importante Classifica le richieste e consente di confrontarle, aiutando a capire se i diversi tipi seguono flussi di processo differenti o presentano colli di bottiglia e tempi di ciclo diversi. Dove reperirli È il campo Tipo di documento, presente nella tabella EBAN, campo BSART. Esempi NBFORV
	Automatizzata IsAutomated	Indicatore che segnala se un’attività è stata svolta da un utente di sistema anziché da una persona.
Descrizione L’attributo Is Automated è un flag booleano che assume valore true quando un’attività viene eseguita da un utente di sistema o batch, ad esempio «WF-BATCH» per le azioni del Workflow. Consente di distinguere le attività manuali da quelle automatizzate. Questo attributo è essenziale per misurare il livello di automazione del processo di richiesta d’acquisto e calcolare il KPI «Tasso di approvazione automatizzata». Filtrando le attività manuali o automatizzate, gli analisti possono confrontarne l’efficienza e individuare ulteriori opportunità di automazione per ridurre i tempi di elaborazione e il lavoro manuale. Perché è importante Distingue le attività svolte da persone da quelle eseguite dai sistemi, un aspetto fondamentale per misurare il livello di automazione e individuare le attività manuali che potrebbero essere automatizzate. Dove reperirli È un attributo derivato, in genere basato su una regola che verifica se l’ID utente associato a un evento appartiene a un elenco di utenti di sistema o batch noti. Esempi truefalse
	Data di consegna richiesta RequiredByDate	La data entro cui il richiedente ha bisogno dei beni o servizi richiesti.
Descrizione La data di consegna richiesta, denominata in SAP data di consegna, specifica quando sono necessari i beni o servizi indicati nella posizione della richiesta. È stabilita dal richiedente e costituisce l’obiettivo temporale dell’intero processo di approvvigionamento. Questo attributo è essenziale per calcolare il KPI «Tasso di completamento puntuale delle richieste». Confrontando la data di consegna richiesta con la data di approvazione finale o di creazione dell’ordine d’acquisto, l’organizzazione può misurare la propria capacità di rispettare i livelli di servizio interni e soddisfare le esigenze aziendali. Analizzare le richieste che non rispettano questa data può far emergere ritardi sistematici nel processo di approvvigionamento. Perché è importante Definisce la data obiettivo per completare una richiesta e consente di misurare la puntualità delle consegne e il rispetto dei livelli di servizio interni. Dove reperirli È la data di consegna, presente a livello di posizione nella tabella EBAN, campo LFDAT. Esempi 2023-11-152023-12-012024-01-20
	È una rilavorazione IsRework	Flag che indica se un’attività costituisce una rilavorazione, ad esempio una modifica apportata dopo l’invio.
Descrizione Is Rework è un flag booleano calcolato che individua le attività ripetitive o prive di valore aggiunto. In questo processo, un esempio comune è l’attività «Richiesta d’acquisto modificata» che si verifica dopo l’invio della richiesta per l’approvazione e costringe a ricominciare il processo di approvazione. Questo attributo è fondamentale per quantificare le rilavorazioni nel processo e il loro impatto sui tempi di ciclo complessivi. La Dashboard Modifiche alle richieste d’acquisto e tasso di rilavorazione utilizza questo flag per evidenziare le inefficienze del processo. Ridurre le rilavorazioni è spesso uno degli obiettivi principali delle iniziative di miglioramento, perché permette di risparmiare tempo e lavoro. Perché è importante Segnala le attività che comportano lavoro ripetuto o inutile, consentendo di misurare direttamente le rilavorazioni e il loro impatto sull’efficienza del processo. Dove reperirli È un attributo calcolato. In genere, la logica contrassegna come rilavorazione ogni attività «Richiesta d’acquisto modificata» che si verifica dopo la prima attività «Richiesta d’acquisto inviata per l’approvazione». Esempi truefalse
	Livello di urgenza UrgencyLevel	Classificazione dell’urgenza della richiesta d’acquisto, che può influire sulla priorità di elaborazione.
Descrizione Il livello di urgenza indica la priorità della richiesta d’acquisto. Anche se non esiste un campo standard dedicato, alcune organizzazioni utilizzano campi come il numero di tracciamento del fabbisogno per registrare questa informazione. In questo modo, chi presenta la richiesta può segnalare esigenze critiche che potrebbero richiedere un’elaborazione più rapida. Analizzare l’impatto dell’urgenza è importante per valutare se il processo assegna effettivamente la priorità alle richieste critiche. La Dashboard Analisi dell’impatto del livello di urgenza utilizza questo attributo per confrontare i tempi di ciclo e i tassi di approvazione delle richieste urgenti con quelli delle richieste standard, aiutando a capire se la gestione prioritaria funziona come previsto. Perché è importante Consente di analizzare le differenze nelle prestazioni del processo per le richieste ad alta priorità e di verificare se quelle urgenti vengono davvero elaborate più rapidamente. Dove reperirli Non esiste un campo standard per l’urgenza. Alcune aziende utilizzano a questo scopo il numero di tracciamento del fabbisogno (EBAN-BEDAR). È possibile che venga utilizzato anche un campo personalizzato. Esempi AltaMediaBassa
	Motivo del rifiuto RejectionReason	Motivo indicato quando una richiesta d’acquisto viene respinta.
Descrizione Il motivo del rifiuto spiega perché un approvatore ha deciso di respingere una richiesta d’acquisto. Tra le possibili ragioni figurano il superamento del budget, informazioni errate, la mancata conformità alle policy o la duplicazione di un’altra richiesta. Queste informazioni sono essenziali per comprendere gli esiti negativi del processo. Analizzare i motivi dei rifiuti aiuta a individuare le cause profonde delle inefficienze e delle rilavorazioni. Ad esempio, se «Centro di costo errato» è una motivazione frequente, potrebbe essere necessario migliorare la formazione degli utenti o i controlli di convalida del sistema. Questo attributo è fondamentale per la Dashboard di analisi dei rifiuti delle richieste d’acquisto e per definire interventi mirati di miglioramento del processo. Perché è importante Indica le cause profonde degli esiti negativi del processo e consente di definire interventi mirati per ridurre le rilavorazioni e aumentare la percentuale di richieste corrette al primo tentativo. Dove reperirli Spesso non è un campo standard. Le informazioni possono essere registrate negli elementi del contenitore del flusso di lavoro, nel testo esteso associato alla richiesta o in campi personalizzati. Esempi Budget superatoFornitore erratoRichiesta duplicata
	Nome della fase di approvazione ApprovalStepName	Nome o descrizione specifica di una fase di approvazione nel Workflow.
Descrizione Il nome della fase di approvazione fornisce una descrizione comprensibile di una determinata fase del Workflow di approvazione, ad esempio «Approvazione del responsabile» o «Approvazione del vicepresidente Finance». È più esplicativo di un’attività generica come «Fase di approvazione completata». Questo attributo è fondamentale per le Dashboard Tempo di ciclo delle fasi di approvazione e Analisi dei colli di bottiglia del Workflow. Offre una visione dettagliata del processo di approvazione e permette di individuare con precisione le fasi che causano i ritardi maggiori e i punti in cui si accumula il lavoro. Questo livello di dettaglio è necessario per intervenire in modo mirato e snellire la catena di approvazione. Perché è importante Fornisce informazioni dettagliate sulle fasi di approvazione e permette di individuare con precisione i colli di bottiglia nel Workflow di approvazione a più livelli. Dove reperirli Questa informazione deriva dalla descrizione dell’attività del Workflow, reperibile collegando il log del Workflow a tabelle con le definizioni delle attività, come T528T. Esempi Approvazione del responsabileApprovazione del direttoreApprovazione del vicepresidente Finance
	Numero dell’ordine d’acquisto PurchaseOrderNumber	Numero dell’ordine d’acquisto creato a partire dalla richiesta.
Descrizione Il numero dell’ordine d’acquisto identifica il documento ufficiale di acquisto creato a partire da una richiesta approvata. La creazione dell’ordine d’acquisto è spesso l’esito finale positivo della richiesta e indica che questa è stata trasformata in un ordine formale presso un fornitore. Questo attributo è fondamentale per misurare il KPI del tempo di attraversamento dalla richiesta all’ordine d’acquisto e il tasso complessivo di conversione. Collega il processo di richiesta a quello di approvvigionamento successivo, consentendo una visione più ampia e completa dell’intero ciclo Purchase-to-Pay. Perché è importante Collega la richiesta al successivo documento di approvvigionamento e consente di misurare il tasso di conversione e il tempo di attraversamento dalla richiesta all’ordine d’acquisto. Dove reperirli Si trova nella tabella EBAN, campo EBELN, una volta creato un ordine d’acquisto a partire dalla posizione della richiesta. Esempi 450001789045000178914500017892
	Ora di fine EndTime	Data e ora esatte in cui è stata completata una determinata attività.
Descrizione EndTime è il timestamp che registra il completamento di un’attività. Molti eventi generati dal sistema sono istantanei, quindi StartTime ed EndTime coincidono, mentre le attività svolte da persone, come le approvazioni, possono avere un orario di inizio e uno di fine distinti. Questo timestamp indica quando il lavoro è stato completato. La disponibilità di un EndTime separato permette di misurare con maggiore precisione il tempo di elaborazione effettivo rispetto ai tempi di attesa. Insieme a StartTime, viene utilizzato per calcolare la metrica ProcessingTime. Questo livello di dettaglio migliora l’analisi dell’utilizzo delle risorse e dell’efficienza delle attività manuali. Perché è importante Indica il completamento di un’attività, consentendo di calcolare il tempo di elaborazione effettivo e di analizzare con maggiore precisione la durata delle attività. Dove reperirli Deriva dai log del Workflow, che possono registrare sia la creazione di un elemento di lavoro (StartTime) sia il suo completamento (EndTime). Esempi 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z
	Sistema di origine SourceSystem	Identifica la specifica istanza SAP S/4HANA da cui sono stati estratti i dati.
Descrizione L’attributo Sistema di origine indica il sistema in cui sono stati generati i dati del processo. Nelle organizzazioni che utilizzano più istanze SAP, ad esempio sistemi distinti per sviluppo, controllo qualità e produzione oppure sistemi separati per diverse aree geografiche, questo campo è fondamentale per la governance dei dati e per comprenderne il contesto. Consente di distinguere i dati provenienti da fonti diverse, evitando aggregazioni errate e permettendo analisi specifiche per sistema. È un attributo obbligatorio per mantenere la tracciabilità della provenienza e garantire che i dati del processo siano rintracciabili. Perché è importante Fornisce informazioni essenziali sull’origine dei dati e sulla relativa governance, soprattutto in ambienti con più sistemi, garantendone la tracciabilità. Dove reperirli In genere è l’ID del sistema SAP (SID), recuperabile dalle variabili di sistema o dalle tabelle di configurazione. Esempi S4PECCS4H_PROD_01
	Ultimo aggiornamento dei dati LastDataUpdate	La data e l’ora dell’ultimo aggiornamento dei dati di questo record dal sistema di origine.
Descrizione Questo attributo registra la data e l’ora dell’estrazione o dell’aggiornamento più recente dei dati dal sistema di origine. È un metadato fondamentale per capire quanto siano aggiornati i dati analizzati. Analisti e utenti aziendali si basano su questa data e ora per sapere se i dati del processo riflettono lo stato operativo più recente. In ogni analisi di processo, conoscere l’attualità dei dati è fondamentale per prendere decisioni informate. Questo attributo aiuta a gestire le aspettative degli utenti e garantisce che le conclusioni si basino su dati aggiornati quanto richiesto dall’analisi. Perché è importante Indica quanto sono aggiornati i dati, un aspetto fondamentale per poter fare affidamento sull’analisi e prendere decisioni aziendali tempestive. Dove reperirli Questa data e ora vengono generate e aggiunte durante il processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Valuta Currency	Codice della valuta dell’importo della richiesta d’acquisto.
Descrizione Questo attributo specifica la valuta in cui è espresso l’importo della richiesta, ad esempio USD, EUR o JPY. Fornisce il contesto necessario per interpretare l’attributo Importo della richiesta d’acquisto, soprattutto nelle organizzazioni multinazionali che operano con più valute. Per ottenere analisi e rendicontazioni finanziarie accurate, è essenziale considerare la valuta. Prima di aggregare o confrontare gli importi delle richieste, occorre convertirli tutti nella stessa valuta per ottenere risultati significativi. Questo attributo è indispensabile per effettuare tali conversioni. Perché è importante Fornisce il contesto necessario per interpretare l’importo della richiesta d’acquisto e consente analisi e confronti finanziari accurati in contesti con più valute. Dove reperirli Si trova nella tabella EBAN, campo WAERS. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Attività di Purchase to Pay - Requisition

Questi sono i passaggi e le tappe fondamentali del processo da registrare nell’Event Log per individuare i processi con precisione.

6 Consigliato 6 Facoltativo

	Attività	Descrizione
	Fase di approvazione completata	Si verifica quando un approvatore approva una richiesta, completando una fase del flusso di lavoro di approvazione multilivello. L’evento viene dedotto da una modifica dello stato di rilascio della richiesta.
Perché è importante Questa attività consente di analizzare nel dettaglio il flusso di lavoro di approvazione e di misurare il tempo impiegato in ogni singola fase. Aiuta a distinguere gli approvatori più efficienti dai colli di bottiglia del processo. Dove reperirli Deducibile dai documenti di modifica (CDHDR/CDPOS) della tabella EBAN. La modifica dello stato del codice di rilascio (ad es. nel campo FRGZU) da non rilasciato a rilasciato per uno specifico codice segnala questo evento. Acquisizione Monitorare le modifiche ai campi dello stato di rilascio in EBAN per ogni codice di rilascio definito nella strategia. Tipo di evento inferred
	Ordine d’acquisto creato	Indica che è stato generato un ordine d’acquisto con riferimento alla posizione della richiesta. È un evento esplicito del sistema che collega la richiesta al successivo documento di approvvigionamento.
Perché è importante È una tappa importante e un esito positivo del processo di richiesta. Il tempo che intercorre tra l’approvazione della richiesta e la creazione dell’ordine d’acquisto è un KPI fondamentale per misurare l’efficienza degli acquisti. Dove reperirli Registrato esplicitamente quando viene creata una posizione dell’ordine d’acquisto. Il collegamento è memorizzato nella tabella EKPO (posizione dell’ordine d’acquisto), che contiene il numero della richiesta di origine (BANFN) e il numero della posizione (BNFPO). Acquisizione Collegare la tabella EKPO alla tabella EBAN utilizzando il numero della richiesta e quello della posizione. La data di creazione della posizione dell’ordine d’acquisto identifica l’evento. Tipo di evento explicit
	Richiesta d’acquisto approvata	Indica l’approvazione definitiva e completa della richiesta d’acquisto, che può così essere convertita in un ordine d’acquisto. La tappa viene dedotta quando lo stato complessivo di rilascio raggiunge lo stato finale di approvazione.
Perché è importante È una tappa fondamentale per il buon esito del processo e un punto di arrivo comune nell’analisi dei tempi di ciclo. Indica che la richiesta ha superato tutti i controlli ed è pronta per essere gestita dall’ufficio acquisti. Dove reperirli Deducibile da una modifica di stato nella tabella EBAN, in particolare quando l’indicatore complessivo di rilascio (FRGZU) o lo stato di elaborazione (PROCSTAT) viene aggiornato al valore finale «Approvato». Acquisizione Individuare la data e l’ora in cui viene applicato il codice di rilascio finale o lo stato complessivo della richiesta passa ad «Approvato». Tipo di evento inferred
	Richiesta d’acquisto chiusa	Indica che la posizione della richiesta è stata elaborata completamente e che non è possibile creare altri ordini d’acquisto a partire da essa. In genere, questo stato viene impostato automaticamente quando è stata ordinata l’intera quantità.
Perché è importante Questa attività rappresenta il completamento definitivo e positivo del ciclo di vita della posizione della richiesta. Conferma che l’esigenza aziendale è stata interamente tradotta in un ordine d’acquisto. Dove reperirli Deducibile dalla tabella EBAN. Si verifica quando viene impostato l’indicatore «Chiuso» (EBAKZ), in genere quando la quantità ordinata negli ordini d’acquisto corrisponde alla quantità richiesta. Acquisizione Individuare, tramite i documenti di modifica, l’evento in cui viene impostato l’indicatore «Chiuso» (EBAKZ) nella tabella EBAN. Tipo di evento inferred
	Richiesta d’acquisto creata	Indica la creazione iniziale del documento di richiesta d’acquisto nel sistema. L’evento viene registrato esplicitamente quando un utente salva per la prima volta una nuova richiesta, memorizzandone la data e l’ora di creazione.
Perché è importante Questa attività costituisce il punto di partenza principale per analizzare il ciclo di vita della richiesta. È essenziale per misurare il tempo di ciclo end-to-end, dall’identificazione dell’esigenza iniziale fino all’approvazione finale o alla conversione in ordine d’acquisto. Dove reperirli È un evento esplicito acquisito dalla tabella EBAN, utilizzando i campi della data di creazione (ERDAT) e dell’ora di creazione (ERZEIT) per il numero specifico della richiesta d’acquisto (BANFN). Acquisizione Utilizzare i campi relativi alla data e all’ora di creazione (ERDAT, ERZEIT) della tabella EBAN per ogni richiesta (BANFN). Tipo di evento explicit
	Richiesta d’acquisto respinta	Indica il rifiuto definitivo della richiesta d’acquisto da parte di un approvatore, che interrompe il processo. L’evento viene registrato tramite un aggiornamento specifico dello stato che segnala il rifiuto.
Perché è importante Questa attività rappresenta un esito negativo definitivo. Analizzare la frequenza e le motivazioni dei rifiuti, nonché le fasi in cui si verificano, aiuta a individuare problemi legati alla conformità alle policy, al budget o alla qualità delle richieste. Dove reperirli Deducibile da una modifica di stato nella tabella EBAN. Lo stato di elaborazione (PROCSTAT) o un indicatore di rilascio viene impostato su un valore che significa esplicitamente «Respinto». Acquisizione Individuare, tramite i documenti di modifica, la data e l’ora in cui lo stato complessivo in EBAN viene aggiornato a «Respinto». Tipo di evento inferred
	Azzeramento dell’approvazione	Indica il ripristino dell’intero flusso di lavoro di approvazione, spesso dovuto a una modifica sostanziale della richiesta. Il processo di approvazione deve quindi ripartire dal primo livello.
Perché è importante Questa attività evidenzia una rilavorazione significativa, che incide pesantemente sul tempo di ciclo. Individuare le cause dell’azzeramento dell’approvazione è fondamentale per semplificare il processo e ridurre i ritardi. Dove reperirli Deducibile dai documenti di modifica (CDHDR/CDPOS) della tabella EBAN. L’evento viene rilevato quando i campi dello stato di rilascio, come FRGKZ o FRGZU, vengono azzerati dopo essere stati impostati parzialmente o completamente. Acquisizione Nei registri delle modifiche, cercare il passaggio dello stato di rilascio da rilasciato a non rilasciato. Tipo di evento inferred
	Fase di approvazione avviata	Indica che la richiesta è in attesa dell’intervento di uno specifico approvatore o gruppo di approvazione. L’evento viene dedotto quando lo stato della richiesta segnala che è in attesa di uno specifico codice di rilascio.
Perché è importante Questa attività è essenziale per individuare i colli di bottiglia nella catena di approvazione. Analizzare la durata di questo stato aiuta a identificare le richieste bloccate e gli approvatori sovraccarichi. Dove reperirli Deducibile dai campi dello stato di rilascio della tabella EBAN (ad es. FRGZU) e dalla configurazione sottostante della strategia di rilascio. L’evento inizia quando uno specifico codice di rilascio diventa il successivo da elaborare. Acquisizione Determinare quando una richiesta entra in uno stato in cui è in attesa dell’approvazione di uno specifico codice di rilascio, sulla base dei registri del flusso di lavoro o dei campi di stato. Tipo di evento inferred
	Fonte di approvvigionamento assegnata	Indica l’azione con cui un addetto agli acquisti assegna a una posizione approvata della richiesta un fornitore, un contratto o un record info specifico. È una fase importante per preparare la richiesta alla creazione dell’ordine d’acquisto.
Perché è importante Questa attività collega l’approvazione all’emissione dell’ordine. Misurare il tempo necessario per assegnare una fonte aiuta a individuare ritardi nel carico di lavoro degli addetti agli acquisti e nell’efficienza dell’approvvigionamento. Dove reperirli Deducibile dall’inserimento di un valore nei campi della tabella EBAN relativi alla fonte di approvvigionamento, come il fornitore fisso (LIFNR), il record info (INFNR) o il contratto (KONNR). Acquisizione Monitorare, tramite i documenti di modifica, la compilazione di campi come LIFNR, INFNR o KONNR nella tabella EBAN. Tipo di evento inferred
	Richiesta d’acquisto inviata per l’approvazione	Indica il momento in cui il richiedente invia formalmente la richiesta, avviando il flusso di lavoro di approvazione. In genere, l’evento viene dedotto quando viene definita la strategia di rilascio della richiesta e lo stato passa a «In approvazione».
Perché è importante È una tappa fondamentale, che avvia il conteggio del tempo di ciclo di approvazione per i KPI. Analizzare il tempo che intercorre tra la creazione e l’invio può far emergere ritardi nella fase di preparazione della richiesta. Dove reperirli Deducibile dai documenti di modifica (CDHDR/CDPOS) della tabella EBAN, in particolare quando vengono compilati i campi della strategia di rilascio (ad es. FRGST) o lo stato complessivo (PROCSTAT) cambia indicando che la richiesta è in approvazione. Acquisizione Individuare la prima voce nei documenti di modifica che segnala l’avvio del flusso di lavoro di approvazione o il passaggio di stato a «In approvazione». Tipo di evento inferred
	Richiesta d’acquisto modificata	Si verifica quando, dopo la creazione iniziale, un utente modifica un campo importante della richiesta, ad esempio la quantità, il prezzo o il materiale. L’azione viene registrata esplicitamente nel sistema dei documenti di modifica di SAP.
Perché è importante Tenere traccia delle modifiche è fondamentale per individuare i cicli di rilavorazione e il loro impatto sui tempi di ciclo. Un numero elevato di modifiche può indicare problemi di qualità dei dati o requisiti in evoluzione, aspetti importanti su cui intervenire per migliorare il processo. Dove reperirli Registrato esplicitamente nelle tabelle dei documenti di modifica di SAP (CDHDR e CDPOS) per le modifiche apportate alla tabella EBAN. Ogni modifica a un campo monitorato genera una voce. Acquisizione Estrarre gli eventi di modifica da CDHDR/CDPOS per i documenti con classe oggetto BANF, relativa alle richieste d’acquisto. Tipo di evento explicit
	Richiesta d’acquisto ritirata	Si verifica quando il richiedente originale annulla o elimina la richiesta prima che sia stata elaborata completamente. In genere, si tratta di un’azione esplicita che imposta un indicatore di eliminazione sulla posizione della richiesta.
Perché è importante Monitorare i ritiri aiuta a comprendere la variabilità della domanda e le ragioni degli annullamenti. Il ritiro porta la richiesta a uno stato terminale, impedendone l’ulteriore elaborazione. Dove reperirli Registrato esplicitamente quando il campo dell’indicatore di eliminazione (LOEKZ) nella tabella EBAN viene impostato per una posizione della richiesta. La modifica viene registrata in CDHDR/CDPOS. Acquisizione Individuare l’evento in cui l’indicatore di eliminazione (LOEKZ) nella tabella EBAN viene impostato su «L». Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da SAP S/4HANA

Passaggi

Prerequisiti: Si assicuri di disporre di un utente con le autorizzazioni necessarie in SAP S/4HANA per accedere alle viste CDS richieste. In genere, sono necessari permessi per oggetti come S_TABU_NAM e l’accesso agli strumenti di visualizzazione dei dati.
Individuazione del metodo di accesso al sistema: Stabilisca come collegarsi al database SAP S/4HANA per eseguire le query SQL. Tra gli strumenti più comuni figurano SAP HANA Studio, l’IDE Eclipse con ADT (ABAP Development Tools) e client SQL di terze parti come DBeaver, che possono collegarsi tramite il client del database SAP HANA.
Revisione della query SQL: Prenda confidenza con lo script SQL fornito. Utilizza Common Table Expressions (CTE) per raccogliere i dati relativi alle diverse attività e unirli in un Event Log unificato.
Personalizzazione dei segnaposto: Individui e sostituisca i segnaposto nella query. Dovrà impostare l’intervallo di date ([YYYY-MM-DD]) per il periodo di estrazione e specificare i codici azienda pertinenti ([Your Company Code]).
Esecuzione della query: Esegua la query SQL completa e personalizzata sul database SAP S/4HANA. Il tempo necessario può variare in base al volume dei dati e all’intervallo di date selezionato.
Revisione iniziale dei dati: Al termine della query, controlli le prime righe dei risultati. Verifichi che tutte le colonne, come PurchaseRequisitionId, ActivityName ed EventTime, siano valorizzate come previsto e che i formati dei dati siano corretti.
Gestione delle trasformazioni dei dati: La query fornita genera dati in un formato pronto per il Process Mining. Le funzioni CAST e CONCAT assicurano la coerenza dei tipi di dati. In genere, non sono necessarie trasformazioni significative dopo l’esecuzione.
Esportazione dell’Event Log: Esporti l’intero insieme dei risultati dal client SQL in un file CSV. Si assicuri che la codifica sia UTF-8 per evitare problemi con i caratteri.
Preparazione del caricamento: Prima di caricare il file in uno strumento di Process Mining, verifichi che il CSV contenga le intestazioni corrette (PurchaseRequisitionId, ActivityName, EventTime e così via) e che il formato di data e ora di EventTime sia coerente e supportato dalla piattaforma di destinazione.
Caricamento in ProcessMind: Carichi il file CSV finale nel progetto ProcessMind. Configuri il progetto associando PurchaseRequisitionId all’ID del caso, ActivityName all’attività ed EventTime al timestamp.

Configurazione

Viste CDS principali: L’estrazione utilizza principalmente I_PurchaseRequisitionAPI01 per i dati essenziali delle richieste d’acquisto, I_ChangeDocument e I_ChangeDocumentItem per tenere traccia delle modifiche e degli aggiornamenti di stato, e I_PurchaseOrderItemAPI01 per collegare le richieste agli ordini d’acquisto.
Autorizzazioni: L’utente che esegue la query deve disporre dell’accesso in lettura alle viste CDS indicate. Si rivolga al team di sicurezza SAP per ottenere i ruoli e le autorizzazioni necessari.
Filtro per intervallo di date: È fondamentale applicare un filtro per data di creazione della richiesta (CreationDate) per limitare il volume dei dati. Per l’analisi iniziale, si consiglia di utilizzare un intervallo compreso tra 3 e 6 mesi.
Filtro organizzativo: Filtri i dati per CompanyCode per assicurarsi di analizzare il processo dell’entità aziendale corretta. Può anche filtrare per PurchaseRequisitionType e concentrarsi su specifici processi di approvvigionamento, ad esempio beni standard o servizi.
Configurazione dei documenti di modifica: La registrazione di attività come «Richiesta d’acquisto modificata» e delle varie fasi di approvazione dipende dall’attivazione della registrazione dei documenti di modifica per i campi pertinenti nel sistema SAP. Se questi eventi non sono presenti, verifichi la configurazione della tabella EBAN nel sistema.
Prestazioni: Nei sistemi molto grandi, con milioni di richieste d’acquisto, l’esecuzione della query su un periodo esteso può incidere sulle prestazioni del sistema. Valuti di eseguirla nelle ore di minore attività o in un ambiente non di produzione con dati aggiornati di recente.

Query di esempio sql

WITH REQUISITIONS AS (
  SELECT
    PurchaseRequisition,
    PurchaseRequisitionType,
    PurReqnDescription,
    CreatedByUser,
    CreationDate,
    CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
    SourceOfSupplyIsAssigned
  FROM I_PurchaseRequisitionAPI01
  WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
    AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
  SELECT
    ObjectValue AS PurchaseRequisition,
    UserName,
    CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
    FieldName,
    ValueNew,
    ValueOld
  FROM I_ChangeDocument AS H
  JOIN I_ChangeDocumentItem AS I
    ON H.ChangeDocument = I.ChangeDocument
  WHERE H.Objectclass = 'EINKBELEG'
    AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
  R.PurchaseRequisition AS "PurchaseRequisitionId",
  'Requisition Created' AS "ActivityName",
  R.CreationTimestamp AS "EventTime",
  R.CreatedByUser AS "UserId",
  NULL AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
  ON R.PurchaseRequisition = I.PurchaseRequisition

UNION ALL

-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
  C.PurchaseRequisition AS "PurchaseRequisitionId",
  CASE
    WHEN C.ValueOld = ''
    THEN 'Requisition Submitted For Approval'
    ELSE 'Approval Step Started'
  END AS "ActivityName",
  C.ChangeTimestamp AS "EventTime",
  R.CreatedByUser AS "UserId",
  NULL AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
  ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
  ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''

UNION ALL

-- 3. Requisition Amended
SELECT DISTINCT
  C.PurchaseRequisition AS "PurchaseRequisitionId",
  'Requisition Amended' AS "ActivityName",
  C.ChangeTimestamp AS "EventTime",
  C.UserName AS "UserId",
  NULL AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
  AND C.ChangeTimestamp > R.CreationTimestamp

UNION ALL

-- 4. Approval Reset
SELECT
  C.PurchaseRequisition AS "PurchaseRequisitionId",
  'Approval Reset' AS "ActivityName",
  C.ChangeTimestamp AS "EventTime",
  C.UserName AS "UserId",
  NULL AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''

UNION ALL

-- 6. Approval Step Completed
SELECT
  C.PurchaseRequisition AS "PurchaseRequisitionId",
  'Approval Step Completed' AS "ActivityName",
  C.ChangeTimestamp AS "EventTime",
  NULL AS "UserId",
  C.UserName AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config

UNION ALL

-- 7. Requisition Approved
SELECT
  C.PurchaseRequisition AS "PurchaseRequisitionId",
  'Requisition Approved' AS "ActivityName",
  C.ChangeTimestamp AS "EventTime",
  NULL AS "UserId",
  C.UserName AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved

UNION ALL

-- 8. Requisition Rejected
SELECT
  C.PurchaseRequisition AS "PurchaseRequisitionId",
  'Requisition Rejected' AS "ActivityName",
  C.ChangeTimestamp AS "EventTime",
  NULL AS "UserId",
  C.UserName AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting

UNION ALL

-- 9. Requisition Withdrawn
SELECT
  C.PurchaseRequisition AS "PurchaseRequisitionId",
  'Requisition Withdrawn' AS "ActivityName",
  C.ChangeTimestamp AS "EventTime",
  C.UserName AS "UserId",
  NULL AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'

UNION ALL

-- 10. Source of Supply Assigned
SELECT DISTINCT
  C.PurchaseRequisition AS "PurchaseRequisitionId",
  'Source of Supply Assigned' AS "ActivityName",
  C.ChangeTimestamp AS "EventTime",
  C.UserName AS "UserId",
  NULL AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
  AND C.ChangeTimestamp > R.CreationTimestamp

UNION ALL

-- 11. Purchase Order Created
SELECT DISTINCT
  I.PurchaseRequisition AS "PurchaseRequisitionId",
  'Purchase Order Created' AS "ActivityName",
  CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
  H.CreatedByUser AS "UserId",
  NULL AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
  'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
  ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
  ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''

UNION ALL

-- 12. Requisition Closed
SELECT
  C.PurchaseRequisition AS "PurchaseRequisitionId",
  'Requisition Closed' AS "ActivityName",
  C.ChangeTimestamp AS "EventTime",
  C.UserName AS "UserId",
  NULL AS "ApproverId",
  R.PurchaseRequisitionType AS "RequisitionType",
  I.CostCenter AS "Department",
  I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
  I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X'

Passaggi

Verifichi che sia disponibile l’accesso diretto in lettura allo schema SAP HANA contenente EBAN ed EBKN e individui gli oggetti dei documenti di modifica e dei documenti d’acquisto utilizzati nel sistema per le modifiche alle richieste, la gestione delle approvazioni, l’assegnazione delle fonti di approvvigionamento, i riferimenti agli ordini d’acquisto e la chiusura. Poiché questi oggetti e campi possono variare in base alla versione e alla configurazione, sostituisca ogni segnaposto tra parentesi quadre nella query con l’oggetto o il campo corrispondente del Suo sistema.
In SAP GUI, utilizzi la transazione SE16H o uno strumento di amministrazione del database approvato per esaminare EBAN ed EBKN, verificare i campi chiave della richiesta e confermare la disponibilità dei campi relativi a data, ora, utente, stato, eliminazione, approvazione, imputazione e riferimenti ai documenti d’acquisto. Utilizzi SE11 o il dizionario dati SAP per verificare le definizioni dei campi. Durante i test, non esponga dati di produzione.
Individui la fonte dei documenti di modifica configurata per le modifiche alle richieste e alle approvazioni. La query si aspetta una fonte normalizzata denominata [Your requisition change document source], con campi per numero e posizione della richiesta, campo modificato, valore precedente, nuovo valore, data e ora della modifica e utente. Prima di eseguire la query, associ questa fonte alle tabelle dei documenti di modifica SAP o alla vista CDS pertinente nel Suo sistema.
Individui la fonte del Workflow o delle approvazioni configurata per l’invio, l’annullamento delle approvazioni, l’avvio e il completamento delle fasi di approvazione, l’approvazione finale e il rifiuto. La query si aspetta [Your requisition approval event source], con una riga per ogni transizione di stato o approvazione e campi per numero e posizione della richiesta, tipo di evento, codice di approvazione o gruppo di approvazione, approvatore, data e ora dell’evento e stato. La associ ai dati persistenti delle approvazioni o del Workflow utilizzati nella configurazione S/4HANA.
Individui le fonti per l’assegnazione delle fonti di approvvigionamento, i riferimenti agli ordini d’acquisto e la chiusura. La query si aspetta [Your requisition source assignment source], [Your requisition purchase order reference source] e [Your requisition closure source]. Associ questi segnaposto a tabelle o viste approvate nel Suo sistema. La creazione di un ordine d’acquisto deve essere rappresentata da un riferimento esplicito dalla posizione dell’ordine alla posizione della richiesta, non dedotta da attività d’acquisto non correlate.
Imposti la finestra di estrazione utilizzando [Start date] e [End date]. Per la prima esecuzione si consiglia un intervallo da tre a sei mesi. Utilizzi un intervallo più ampio solo dopo aver verificato le prestazioni del database e il volume degli eventi. La query applica filtri alle date di creazione e agli eventi, mantenendo l’identificativo della richiesta come identificativo del caso.
Esegua la query in un client SQL approvato, collegato a SAP HANA. Sostituisca solo i dettagli di connessione esterni alla query, i parametri delle date, i filtri specifici dell’azienda e i segnaposto di fonti e campi documentati esplicitamente. Mantenga esattamente i nomi delle colonne di output: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount e RequisitionStatus.
Verifichi la presenza di eventi duplicati, la precisione dei timestamp, la gestione dei fusi orari e il livello di dettaglio per posizione o documento. La query genera identificativi del caso a livello di documento e include internamente il contesto della posizione. Se più posizioni generano la stessa attività allo stesso timestamp, mantenga righe separate, a meno che la configurazione di ProcessMind non richieda esplicitamente la deduplicazione.
Verifichi che ogni attività richiesta compaia come valore di ActivityName, che EventTime sia valorizzato e cronologicamente plausibile e che l’identificativo del caso obbligatorio non sia nullo. Confronti i conteggi con i report SAP o con estrazioni operative approvate per lo stesso intervallo di date.
Esporti i risultati in un file CSV UTF-8 o in un altro formato tabellare supportato da ProcessMind. Includa una riga di intestazione, mantenga timestamp compatibili con il formato ISO, lasci vuoti i valori nulli e carichi il file utilizzando PurchaseRequisitionId come identificativo del caso, ActivityName come colonna delle attività ed EventTime come colonna dei timestamp.

Configurazione

Identificativo del caso: Utilizzi il numero del documento della richiesta d’acquisto in EBAN, rappresentato da PurchaseRequisitionId. Se il processo è configurato a livello di posizione, utilizzi invece una chiave composta documentata, ad esempio numero e posizione della richiesta, applicandola a ogni evento.
Fonte principale: EBAN contiene i dati delle posizioni delle richieste d’acquisto. EBKN contiene i dati dell’imputazione, utili per arricchire le informazioni su reparto o centro di costo. Prima dell’esecuzione, verifichi nel dizionario dati SAP i nomi esatti e i tipi di dati dei campi.
Fonti degli eventi: La query utilizza segnaposto espliciti per le fonti di modifica, approvazione, assegnazione delle fonti di approvvigionamento, riferimenti agli ordini d’acquisto e chiusura, poiché tali fonti dipendono dalla versione di S/4HANA, dalla progettazione del Workflow, dalla procedura di approvazione, dalle funzioni aziendali attivate e dalle estensioni del cliente.
Intervallo di date: Inizi con un periodo da tre a sei mesi. Se disponibili, utilizzi un intervallo delimitato sui campi data indicizzati o che consentono l’esclusione delle partizioni. Per i caricamenti incrementali, sovrapponga gli intervalli di estrazione quanto basta per acquisire le modifiche arrivate in ritardo, quindi deduplichi in base a caso, attività, timestamp, posizione e chiave dell’evento di origine.
Filtri aziendali: Configuri [Company code filter], [Document type filter], [Purchasing group filter] e [Plant filter] solo se i campi sono disponibili e il loro significato aziendale è stato verificato. Eviti di filtrare per stato se l’obiettivo è acquisire l’intero ciclo di vita.
Mappatura degli stati: Configuri i valori relativi a In Approval, approvazione finale, rifiuto, annullamento, codice di approvazione in sospeso e chiusura in base alla strategia di approvazione o alla configurazione del Workflow del sistema di destinazione. Non presuma che un codice di stato sia valido per tutti i client SAP.
Mappatura delle modifiche: Includa le modifiche a quantità, prezzo, materiale, data di consegna, imputazione e agli altri campi considerati fondamentali per il processo. La query include condizioni esplicite per i campi chiave elencati e richiede che la fonte esponga il nome del campo modificato.
Gestione dei timestamp: Combini la data e l’ora dell’evento nel fuso orario del database, documentando poi ogni conversione in UTC. Se una fonte memorizza solo la data, utilizzi la mezzanotte solo quando non è disponibile un timestamp più preciso e registri questa limitazione.
Prestazioni: Limiti l’estrazione iniziale per data e ambito aziendale, selezioni solo le colonne necessarie, eviti join senza restrizioni con tabelle di grandi dimensioni contenenti lo storico delle modifiche o del Workflow e controlli il piano di esecuzione di HANA. Se sono necessarie estrazioni ripetute, materializzi o prepari le fonti degli eventi normalizzate.
Autorizzazioni e prerequisiti: Ottenga l’autorizzazione in lettura per EBAN, EBKN, le fonti configurate per le modifiche e il Workflow, i dati di assegnazione delle fonti di approvvigionamento, i riferimenti agli ordini d’acquisto e i dati di chiusura. Verifichi che l’accesso diretto al database sia approvato, che le funzionalità di acquisto e Workflow pertinenti siano attive e che siano disponibili le licenze del database SAP HANA o gli strumenti di amministrazione necessari.
Sicurezza: Applichi il principio del privilegio minimo, protegga gli identificativi degli utenti e degli approvatori e rispetti le regole aziendali per l’estrazione di informazioni sugli acquisti e finanziarie.

Query di esempio sql

WITH
base_items AS (
    SELECT
        eban.[Purchase requisition number field] AS PurchaseRequisitionId,
        eban.[Purchase requisition item field] AS RequisitionItem,
        eban.[Creation date field] AS CreationDate,
        eban.[Creation time field] AS CreationTime,
        eban.[Created by field] AS CreatedBy,
        eban.[Requisition type field] AS RequisitionType,
        eban.[Company code field] AS CompanyCode,
        eban.[Plant field] AS Plant,
        eban.[Purchasing group field] AS PurchasingGroup,
        eban.[Quantity field] AS Quantity,
        eban.[Net price field] AS NetPrice,
        eban.[Currency field] AS Currency,
        eban.[Material field] AS Material,
        eban.[Deletion indicator field] AS DeletionIndicator,
        eban.[Overall release status field] AS OverallReleaseStatus,
        eban.[Item processing status field] AS ItemProcessingStatus,
        ebkn.[Cost center field] AS CostCenter,
        ebkn.[Department field] AS Department,
        CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
    FROM [Your SAP schema].EBAN eban
    LEFT JOIN [Your SAP schema].EBKN ebkn
        ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
       AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
    WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
      AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
      AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
      AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
      AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
    SELECT
        PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        CreatedBy AS UserId,
        CAST(NULL AS NVARCHAR(80)) AS ApproverId,
        RequisitionType,
        Department,
        RequisitionAmount,
        'Created' AS RequisitionStatus
    FROM base_items
),
submitted_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Requisition Submitted For Approval' AS ActivityName,
        TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        a.[Requester or submitter field] AS UserId,
        CAST(NULL AS NVARCHAR(80)) AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        a.[Status field] AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition approval event source] a
        ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND a.[Purchase requisition item field] = b.RequisitionItem
    WHERE a.[Event type field] = 'SUBMITTED'
       OR a.[Status field] = 'In Approval'
),
amended_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        c.[Change user field] AS UserId,
        CAST(NULL AS NVARCHAR(80)) AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        'Amended' AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition change document source] c
        ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND c.[Purchase requisition item field] = b.RequisitionItem
    WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Approval Reset' AS ActivityName,
        TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        a.[Event user field] AS UserId,
        CAST(NULL AS NVARCHAR(80)) AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        a.[Status field] AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition approval event source] a
        ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND a.[Purchase requisition item field] = b.RequisitionItem
    WHERE a.[Event type field] = 'RESET'
       OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        CAST(NULL AS NVARCHAR(80)) AS UserId,
        a.[Approver or approval group field] AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        a.[Status field] AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition approval event source] a
        ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND a.[Purchase requisition item field] = b.RequisitionItem
    WHERE a.[Event type field] = 'STEP_STARTED'
       OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Approval Step Completed' AS ActivityName,
        TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        CAST(NULL AS NVARCHAR(80)) AS UserId,
        a.[Approver or approval group field] AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        a.[Status field] AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition approval event source] a
        ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND a.[Purchase requisition item field] = b.RequisitionItem
    WHERE a.[Event type field] = 'STEP_COMPLETED'
       OR a.[Status field] = 'Step Approved'
),
approved_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        CAST(NULL AS NVARCHAR(80)) AS UserId,
        a.[Approver or approval group field] AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        a.[Status field] AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition approval event source] a
        ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND a.[Purchase requisition item field] = b.RequisitionItem
    WHERE a.[Event type field] = 'FINAL_APPROVED'
       OR a.[Status field] = 'Approved'
),
rejected_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        CAST(NULL AS NVARCHAR(80)) AS UserId,
        a.[Approver or approval group field] AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        a.[Status field] AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition approval event source] a
        ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND a.[Purchase requisition item field] = b.RequisitionItem
    WHERE a.[Event type field] = 'REJECTED'
       OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        c.[Change user field] AS UserId,
        CAST(NULL AS NVARCHAR(80)) AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        'Withdrawn' AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition change document source] c
        ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND c.[Purchase requisition item field] = b.RequisitionItem
    WHERE c.[Changed field field] = 'DELETION_INDICATOR'
      AND c.[New value field] IS NOT NULL
      AND c.[New value field] <> ''
),
source_assigned_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Source of Supply Assigned' AS ActivityName,
        TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        s.[Event user field] AS UserId,
        CAST(NULL AS NVARCHAR(80)) AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        'Source Assigned' AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition source assignment source] s
        ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND s.[Purchase requisition item field] = b.RequisitionItem
    WHERE s.[Source identifier field] IS NOT NULL
      AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        p.[Purchase order creator field] AS UserId,
        CAST(NULL AS NVARCHAR(80)) AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        'Purchase Order Created' AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition purchase order reference source] p
        ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND p.[Purchase requisition item field] = b.RequisitionItem
    WHERE p.[Purchase order number field] IS NOT NULL
      AND p.[Purchase order number field] <> ''
),
closed_events AS (
    SELECT
        b.PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
        cl.[Event user field] AS UserId,
        CAST(NULL AS NVARCHAR(80)) AS ApproverId,
        b.RequisitionType,
        b.Department,
        b.RequisitionAmount,
        cl.[Status field] AS RequisitionStatus
    FROM base_items b
    INNER JOIN [Your requisition closure source] cl
        ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
       AND cl.[Purchase requisition item field] = b.RequisitionItem
    WHERE cl.[Event type field] = 'CLOSED'
       OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

È pronto a iniziare?

Utilizzi questo template per preparare i dati con sicurezza e sfruttare appieno il potenziale del Process Mining nel processo Purchase to Pay - Requisition. Inizi oggi a migliorare l’efficienza!

Torna alla guida al miglioramento

Scarica il template

Riduca i ritardi nelle richieste d’acquisto P2P: ottimizzi subito il flusso di lavoro!

Snellisca i processi, riduca i tempi di attraversamento e accorci del 30% i tempi di ciclo.

Inizi la prova gratuita

Non è richiesta una carta di credito; la configurazione richiede 5 minuti.

Il Suo Template di dati per Purchase to Pay - Requisition

Il Suo Template di dati per Purchase to Pay - Requisition

Attributi di Purchase to Pay - Requisition

Attività di Purchase to Pay - Requisition

Guide all’estrazione

Estrazione delle viste CDS di SAP S/4HANA per le richieste d’acquisto

Passaggi

Configurazione

Query di esempio sql

Query diretta al database sulle tabelle delle richieste d’acquisto di SAP HANA

Passaggi

Configurazione

Query di esempio sql

È pronto a iniziare?

Riduca i ritardi nelle richieste d’acquisto P2P: ottimizzi subito il flusso di lavoro!