> Miglioramento Continuo dei Processi > Dall'Acquisto al Pagamento Richiesta > Microsoft Dynamics 365 > Template Dati

Il Suo template per i dati delle richieste Purchase to Pay

Microsoft Dynamics 365

Attributi di Dall'Acquisto al Pagamento - Richiesta (18) Attività di Dall'Acquisto al Pagamento - Richiesta (12) Guide all'Estrazione (3)

Il Suo template per i dati delle richieste Purchase to Pay

Questo `template` delinea gli attributi chiave da raccogliere e le attività cruciali da tracciare, consentendo un'analisi approfondita del Suo processo di richiesta. Fornisce inoltre una guida pratica sull'estrazione di questi `dati`, aiutandoLa a preparare il Suo `event log` in modo efficiente per un'analisi dettagliata.

Attributi consigliati da raccogliere
Attività chiave da tracciare
Guida all'estrazione

È nuovo agli event log? Impari come creare un event log di Process Mining.

Scarica Template

Attributi di Dall'Acquisto al Pagamento - Richiesta

Questi sono i campi `dati` raccomandati da includere nel Suo `event log` per un'analisi completa del Suo processo Dall'Acquisto al Pagamento - Richiesta.

5 Obbligatorio 7 Consigliato 6 Facoltativo

	Nome	Descrizione
	ID requisizione d’acquisto PurchaseRequisitionId	L'identificatore univoco per una richiesta di acquisto, che funge da identificatore di `case` primario.
Descrizione Il `Purchase Requisition ID` è la chiave centrale che collega tutte le attività relative a una singola richiesta di beni o servizi. Ogni processo di richiesta, dalla creazione all'approvazione finale e alla chiusura, è tracciato sotto questo ID univoco. Nel `Process Mining`, questo attributo è fondamentale per ricostruire il percorso `end-to-end` di ogni richiesta. Consente l'analisi delle varianti di processo, dei tempi di ciclo e della `compliance` per i singoli casi, offrendo una visione completa del ciclo di vita della richiesta. Perché è importante È essenziale per raggruppare tutti gli `eventi` correlati in una singola istanza di processo, consentendo un'analisi completa, end-to-end, del ciclo di vita di ciascuna richiesta. Dove trovare Questa è tipicamente la chiave primaria nella tabella `header` principale della richiesta di acquisto, come PurchReqTable in Microsoft Dynamics 365. Esempi PR-001254PR-001255PR-001256
	Nome attività ActivityName	Il nome dello specifico `event` o passaggio di `business` che si è verificato nel processo di richiesta.
Descrizione Questo attributo registra il nome di ogni attività eseguita all'interno del ciclo di vita della richiesta di acquisto. Esempi includono 'Richiesta Creata', 'Fase di Approvazione Approvata' e 'Ordine di Acquisto Creato'. Queste attività formano i nodi nella mappa di processo scoperta. Analizzare la sequenza, la frequenza e la durata tra queste attività è il cuore del `Process Mining`. Aiuta a identificare i `bottleneck`, i cicli di rielaborazione e le deviazioni dal flusso di processo standard, fornendo `insight` sulle inefficienze operative. Perché è importante Questo attributo definisce i passaggi nella mappa di processo, rendendo possibile visualizzare, analizzare e comprendere il `workflow` di richiesta. Dove trovare Questo è tipicamente derivato dai `log` di cambio stato, dalle tabelle di cronologia del `workflow` o dalle tabelle di `event` specifiche all'interno di Microsoft Dynamics 365, come WorkflowTrackingStatusTable. Esempi Richiesta Inviata per ApprovazioneFase di Approvazione ApprovataRichiesta Modificata
	Timestamp Evento EventTime	Il timestamp preciso quando si è verificata un'attività o un evento specifico.
Descrizione Event Time, o il `timestamp`, cattura la data e l'ora in cui un `evento` aziendale è stato registrato nel sistema. È il fondamento temporale per tutte le analisi di processo basate sul tempo. Questo `attributo` è fondamentale per il calcolo dei tempi di ciclo, delle durate e dei tempi di attesa tra le attività. Consente l'analisi delle prestazioni del processo, l'identificazione dei `colli di bottiglia` e il monitoraggio della `conformità` agli `SLA`. `Timestamp` accurati sono essenziali per un'analisi `process mining` affidabile. Perché è importante Fornisce l'ordine cronologico degli `eventi`, necessario per calcolare le durate dei processi, identificare i `colli di bottiglia` e analizzare le prestazioni nel tempo. Dove trovare Trovato nella cronologia del `workflow` o nelle tabelle dei `log` dei documenti, spesso come campo `CreatedDateTime` o `ModifiedDateTime` associato a ogni cambiamento di stato o record di `evento`. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
	Sistema di Origine SourceSystemId	Il sistema di origine da cui sono stati estratti i dati.
Descrizione Questo attributo identifica il sistema sorgente da cui hanno avuto origine i `dati` `event`. In questo contesto, sarebbe 'Microsoft Dynamics 365'. In ambienti con più sistemi integrati, questo campo è cruciale per la `data lineage` e il contesto. Nell'analisi, aiuta a differenziare i processi che possono estendersi su più sistemi o conferma che i `dati` provengono da un'unica fonte autorevole. Questo è importante per la validazione dei `dati` e per garantire che l'analisi si basi sul `dataset` corretto. Perché è importante Fornisce contesto sull'origine dei `dati`, il che è cruciale per la `data governance`, la convalida e in ambienti in cui più sistemi sono integrati. Dove trovare Questo è un valore statico, 'Microsoft Dynamics 365', aggiunto durante il processo di estrazione e trasformazione dei `dati`. Esempi Microsoft Dynamics 365 F&OD365MSD365
	Ultimo `Data Update` LastDataIngestionTimestamp	Il `timestamp` di quando i `dati` sono stati estratti e caricati per l'ultima volta nello strumento di `Process Mining`.
Descrizione Questo attributo indica l'attualità dei `dati` analizzati. Mostra la data e l'ora dell'ultimo aggiornamento dei `dati` dal sistema sorgente. Questo non è un campo di Dynamics 365, bensì `metadata` aggiunti durante l'ingestione dei `dati`. Questo `timestamp` è critico affinché gli utenti comprendano la tempestività degli `insight`. Li aiuta a sapere se stanno esaminando `dati` in tempo reale o un'istantanea di un momento specifico, il che influisce sulla rilevanza delle loro conclusioni. Perché è importante Informa gli utenti sulla freschezza dei dati, assicurando che comprendano il lasso di tempo dell'analisi e la rilevanza delle intuizioni. Dove trovare Questo valore è generato e aggiunto al `dataset` durante il processo di ingestione dei `dati` o ETL. Esempi 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Dipartimento Department	Il dipartimento del richiedente o il centro di costo associato alla richiesta.
Descrizione Questo attributo specifica il dipartimento aziendale o il centro di costo che ha avviato la richiesta di acquisto, come 'Marketing', 'IT' o 'Operations'. Questa informazione fa solitamente parte dell'header della richiesta. Segmentare il processo per dipartimento è cruciale per l'analisi comparativa. Le permette di vedere quali dipartimenti hanno i tempi di ciclo più lunghi, i tassi di rifiuto più alti o le modifiche più frequenti. Questi `insight` aiutano a personalizzare i miglioramenti del processo in base alle esigenze specifiche del dipartimento. Perché è importante Consente di filtrare e confrontare le prestazioni del processo tra diverse unità aziendali, rivelando schemi, `colli di bottiglia` o inefficienze specifici del dipartimento. Dove trovare Questa informazione è spesso memorizzata nell'header della richiesta di acquisto (PurchReqTable) e collegata alla configurazione delle dimensioni finanziarie in Dynamics 365. Esempi Reparto ITFinanzaOperazioni
	Fase di Approvazione ApprovalStep	Il nome o la fase di un passaggio di approvazione specifico nel `workflow`.
Descrizione Questo attributo identifica la fase specifica nel `workflow` di approvazione, come 'Approvazione del Manager' o 'Approvazione Finanziaria'. Fornisce un dettaglio più granulare rispetto al nome generico dell'attività. Questo attributo è essenziale per l''Analisi dei `Bottleneck` dei Passaggi di Approvazione'. Monitorando il tempo trascorso in ogni fase di approvazione distinta, diventa possibile individuare esattamente quali stadi causano ritardi nel processo complessivo. Ciò consente interventi mirati per migliorare l'efficienza del `workflow`. Perché è importante Permette un'analisi granulare del `workflow` di approvazione, rendendo possibile identificare le fasi specifiche che stanno causando `colli di bottiglia`. Dove trovare Questa informazione è contenuta nelle tabelle di cronologia del `workflow`, come WorkflowTrackingStatusTable, che dettagliano ogni passaggio del `workflow` configurato. Esempi Approvazione del ResponsabileApprovazione Responsabile di DipartimentoRevisione Finanziaria
	Importo Totale della Richiesta RequisitionTotalAmount	Il valore monetario totale della richiesta di acquisto.
Descrizione Questo attributo cattura il valore totale di tutte le voci di riga di una richiesta di acquisto. L'importo spesso influenza la complessità del `workflow` di approvazione, con richieste di valore più elevato che richiedono più fasi di approvazione. Nell'analisi di processo, questo attributo è essenziale per il filtraggio e l'analisi basati sul valore. Aiuta a rispondere a domande come: 'Le richieste di alto valore impiegano più tempo per essere approvate?' o 'Qual è il valore delle richieste attualmente bloccate nel processo?'. Questo fornisce un contesto finanziario alle `performance` del processo. Perché è importante Aggiunge una dimensione finanziaria all'analisi, consentendo la prioritizzazione dei `case` di alto valore e la comprensione di come il valore monetario influisce sul comportamento del processo. Dove trovare Questo valore si trova tipicamente nella tabella `header` della richiesta di acquisto o è calcolato come somma degli importi delle voci di linea dalla tabella delle linee della richiesta di acquisto (PurchReqLine). Esempi 1500.0025000.50500.75
	Livello di Urgenza UrgencyLevel	Una classificazione dell'urgenza della richiesta, come 'Alta', 'Media' o 'Bassa'.
Descrizione Il Livello di Urgenza, o priorità, indica quanto rapidamente sono necessari i beni o servizi richiesti. Questo attributo è spesso utilizzato per influenzare il percorso di approvazione o per prioritizzare il lavoro per gli approvatori. L'analisi di questo attributo aiuta a determinare se il sistema di priorità è efficace. Ad esempio, è possibile confrontare i tempi di ciclo delle richieste con urgenza "Alta" rispetto a quelle con urgenza "Bassa". Se non vi è alcuna differenza significativa, ciò potrebbe indicare che il campo della priorità viene ignorato o utilizzato in modo improprio, un `insight` chiave per la `dashboard` 'Analisi dell'impatto del livello di urgenza'. Perché è importante Aiuta a valutare se le impostazioni di priorità accelerano efficacemente le richieste critiche e scopre il potenziale uso improprio della classificazione di urgenza. Dove trovare Questo potrebbe essere un campo standard o personalizzato nella PurchReqTable. La sua esistenza e il suo nome possono variare in base alla configurazione del sistema. Esempi ElevatoMedioBasso
	Stato della Richiesta RequisitionStatus	Lo stato attuale o finale della richiesta di acquisto.
Descrizione Questo attributo indica lo stato complessivo della richiesta di acquisto in qualsiasi momento, come 'In Revisione', 'Approvato', 'Rifiutato' o 'Chiuso'. Si tratta spesso di un attributo a livello di caso che rappresenta l'esito finale. L'analisi dello stato finale aiuta a comprendere gli esiti complessivi del processo. Ad esempio, un numero elevato di richieste 'Rifiutate' o 'Ritirate' può indicare problemi nella fase iniziale della richiesta o un processo di approvazione macchinoso. È fondamentale per misurare i tassi di successo e l'efficienza del processo. Perché è importante Fornisce un risultato chiaro per ogni `case`, consentendo l'analisi dei tassi di approvazione, rifiuto e ritiro, che sono indicatori chiave di prestazione. Dove trovare Il campo `status` si trova tipicamente nella tabella `header` della richiesta di acquisto, PurchReqTable, spesso denominato 'Status' o 'PurchReqStatus'. Esempi ApprovatoIn revisioneRifiutatoBozza
	Tempo di Elaborazione ProcessingTime	Il tempo attivo dedicato a una specifica attività.
Descrizione Il Tempo di Elaborazione rappresenta la durata che una risorsa impiega attivamente nell'esecuzione di un compito. È calcolato come la differenza tra l'ora di fine e l'ora di inizio di un'attività. A differenza del tempo di ciclo, esclude il tempo di attesa o di coda. Questa metrica calcolata è vitale per comprendere l'efficienza delle risorse e lo sforzo effettivo richiesto per ogni passaggio del processo. Aiuta nell''Analisi dei `Colli di Bottiglia` della Fase di Approvazione' distinguendo tra lunghi tempi di elaborazione, che possono indicare un compito complesso, e lunghi tempi di coda, che suggeriscono un problema di disponibilità delle risorse. Perché è importante Misura la durata del lavoro attivo per le attività, aiutando a distinguere tra tempo a valore aggiunto e tempo di attesa per un'analisi accurata dei `colli di bottiglia`. Dove trovare Questo è calcolato durante la trasformazione dei `dati` sottraendo il tempo di inizio di un'attività dal suo tempo di fine. Ciò richiede di avere sia StartTime che EndTime per ogni attività. Esempi 864000003600000600000
	Utente User	L'ID utente o il nome della persona che ha eseguito l'attività.
Descrizione Questo attributo identifica il dipendente o l'utente di sistema responsabile dell'esecuzione di una fase di processo specifica, come l'invio di una richiesta o l'approvazione di una richiesta. Può essere un ID utente, il nome completo o l'indirizzo email. L'analisi delle attività per utente aiuta a identificare le esigenze di formazione, gli individui o i team con `performance` elevate e la distribuzione del carico di lavoro. È anche essenziale per l'analisi della `compliance`, come la segregazione dei compiti, e per comprendere come i diversi ruoli utente interagiscono con il processo. Perché è importante Consente l'analisi del comportamento specifico dell'utente, del carico di lavoro e delle prestazioni, il che è fondamentale per la gestione delle risorse e l'identificazione delle opportunità di formazione. Dove trovare Tipicamente trovato nelle tabelle di cronologia del `workflow` (ad es. WorkflowTrackingStatusTable) o nelle tabelle di transazione (ad es. PurchReqTable) collegate a una tabella utente (ad es. UserInfo). Esempi j.smitha.joness.patel
	Conteggio Modifiche AmendmentCount	Il numero totale di volte in cui una richiesta è stata modificata.
Descrizione Questo è un attributo numerico calcolato che conta le occorrenze dell'attività 'Richiesta Modificata' per ogni caso di richiesta di acquisto. Questo attributo è essenziale per la `dashboard` 'Frequenza delle Modifiche delle Richieste' e il KPI 'Rapporto di Modifica delle Richieste'. Quantifica la quantità di rielaborazione per caso, rendendo facile identificare quali richieste, dipartimenti o utenti sono associati a livelli elevati di cambiamento e inefficienza. Questo aiuta a indirizzare gli sforzi per migliorare la qualità iniziale della richiesta. Perché è importante Quantifica la rilavorazione all'interno di un `case`, rendendo facile misurare e analizzare la frequenza delle modifiche e il loro impatto sull'efficienza del processo. Dove trovare Questo è un attributo calcolato. Viene derivato durante la trasformazione dei `dati` contando le attività 'Richiesta Modificata' per ogni `PurchaseRequisitionId` univoco. Esempi 013
	È Approvato al Primo Passaggio IsFirstPass	Un `flag` che indica se una richiesta è stata approvata senza modifiche o rifiuti precedenti.
Descrizione Questo è un attributo booleano calcolato che è 'true' se il percorso di approvazione di una richiesta non ha incluso attività 'Richiesta Modificata' o 'Fase di Approvazione Rifiutata'. Altrimenti, è 'false'. Questo attributo supporta direttamente il KPI 'Tasso di Approvazione al Primo Passaggio della Richiesta'. Semplifica l'analisi dell'efficienza del processo fornendo un chiaro indicatore di rielaborazione a livello di caso. Un basso tasso di approvazioni al primo passaggio evidenzia problemi con la qualità iniziale dei `dati` o requisiti poco chiari, segnalando un'opportunità di miglioramento del processo. Perché è importante Misura direttamente la qualità e l'efficienza del processo identificando i `case` che hanno richiesto rilavorazione, supportando i `KPI` focalizzati sui tassi di "first-time-right". Dove trovare Questo è un attributo calcolato. Richiede l'analisi della sequenza completa delle attività per ogni caso durante la trasformazione dei `dati` per verificare l'assenza di attività di rielaborazione prima dell'approvazione. Esempi truefalse
	Gruppo di approvatori ApproverGroup	Il gruppo di utenti o il ruolo responsabile di una fase di approvazione.
Descrizione Questo attributo identifica il gruppo, il ruolo o la coda assegnati per gestire una specifica attività di approvazione, ad esempio 'Approvatori Finanziari' o 'Manager IT'. Analizzare le `performance` del processo per gruppo di approvatori è fondamentale per comprendere la distribuzione del carico di lavoro e identificare quali gruppi potrebbero essere sotto-dotati di risorse o richiedere formazione aggiuntiva. Supporta direttamente la `dashboard` 'Analisi dei `Bottleneck` dei Passaggi di Approvazione' consentendo di segmentare le `performance` in base ai team responsabili delle approvazioni. Perché è importante Aiuta a identificare le differenze di prestazioni tra i `team` di approvazione, evidenziando potenziali vincoli di risorse o esigenze di formazione all'interno di gruppi specifici. Dove trovare Questa informazione fa parte della cronologia del `workflow` (ad es. WorkflowTrackingStatusTable), che registra l'utente assegnato o il gruppo di utenti per ogni attività. Esempi Approvatori FinanziariResponsabili ITAlta Direzione
	Numero Ordine d'Acquisto PurchaseOrderNumber	L'identificatore dell'ordine di acquisto creato dalla richiesta.
Descrizione Questo attributo memorizza l'ID univoco dell'ordine di acquisto generato da una richiesta di acquisto approvata. Serve da collegamento tra il processo di richiesta e il processo di `procurement` a valle. Tracciare questo numero è essenziale per analizzare il 'Tempo di Conversione Richiesta a Ordine di Acquisto'. Conferma che una richiesta è passata con successo alla fase successiva del ciclo Dall'Acquisto al Pagamento e consente un'analisi di processo `end-to-end` che copre sia le richieste che gli ordini di acquisto. Perché è importante Collega la richiesta al successivo ordine di acquisto, consentendo l'analisi della conversione Richiesta-Ordine di Acquisto e collegando diverse fasi del processo P2P. Dove trovare Questa informazione si trova solitamente nella tabella delle linee della richiesta di acquisto (PurchReqLine) dopo che un PO è stato creato, collegandosi alla PurchTable. Esempi PO-000987PO-000988PO-000989
	Percorso `Workflow` di Approvazione ApprovalWorkflowPath	Una rappresentazione della sequenza di passaggi di approvazione eseguiti.
Descrizione Questo attributo è un campo derivato che concatena la sequenza delle fasi di approvazione per una data richiesta, come 'Approvazione del Manager -> Approvazione del Capo Dipartimento -> Approvazione Finanza'. Riepiloga efficacemente la variante di processo per il sotto-processo di approvazione. Questo è cruciale per la `dashboard` 'Monitoraggio delle Deviazioni di `Compliance`'. Confrontando il percorso del `workflow` effettivo con un percorso standard o atteso predefinito, diventa facile segnalare flussi di processo non conformi o insoliti che potrebbero rappresentare violazioni delle politiche o rischi operativi. Perché è importante Semplifica l'analisi della `conformità` fornendo una chiara rappresentazione `stringa` della variante del processo, rendendo facile individuare le deviazioni dalle procedure standard. Dove trovare Questo attributo non è un campo standard. Deve essere derivato concatenando i valori di 'ApprovalStep' in ordine cronologico per ogni caso durante la trasformazione dei `dati`. Esempi Manager -> DirettoreManager -> Direttore -> VP FinanzaManager -> Approvato Automaticamente
	Valuta Currency	Il codice valuta per l'importo della richiesta.
Descrizione Questo attributo specifica la valuta, ad esempio USD, EUR, GBP, in cui è denominato l'importo totale della richiesta. È cruciale per l'analisi finanziaria, specialmente nelle organizzazioni multinazionali che gestiscono più valute. L'utilizzo dell'attributo valuta consente una corretta gestione e aggregazione dei `dati` finanziari. Assicura che i valori monetari siano interpretati correttamente e abilita le conversioni a una valuta comune per `reporting` e confronti accurati tra diverse regioni o unità di `business`. Perché è importante Fornisce il contesto necessario per gli `attributi` finanziari, garantendo un'interpretazione e un'aggregazione accurate dei valori monetari in ambienti multi-valuta. Dove trovare Questo campo si trova tipicamente nella tabella `header` della richiesta di acquisto, PurchReqTable, insieme ai campi importo. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Attività di Dall'Acquisto al Pagamento - Richiesta

Questi sono i passaggi di processo e le `milestone` essenziali da catturare nel Suo `event log` per una scoperta e analisi accurate del Suo `workflow` di richiesta.

7 Consigliato 5 Facoltativo

	Activity	Descrizione
	Fase di Approvazione Approvata	Un approvatore completa il compito assegnato, approvando la richiesta per la sua fase del processo. Questo sposta la richiesta al passaggio successivo o all'approvazione finale.
Perché è importante Misura il tempo di elaborazione per ogni fase di approvazione e aiuta a individuare le parti efficienti del `workflow`. È un componente chiave dell'analisi delle varianti. Dove trovare Registrato esplicitamente nella `WorkflowTrackingStatusTable` quando un utente completa un elemento di lavoro con un esito 'Approva'. Acquisisci Identificare gli `eventi` 'WorkItemCompleted' con esito 'Approva' nei `log` di cronologia del `workflow`. Tipo di evento explicit
	Ordine di acquisto creato	Una riga di richiesta d'acquisto approvata viene convertita in una riga d'ordine di acquisto, segnalando il passaggio al `team` di approvvigionamento. Questo viene catturato collegando la riga della richiesta alla riga dell'ordine di acquisto.
Perché è importante Questo è una `milestone` critica che collega la richiesta al processo di `procurement` a valle. È essenziale per misurare il KPI 'Tempo di Conversione Richiesta a PO'. Dove trovare Inferito trovando un record nella tabella `PurchLine` che fa riferimento all'ID di una `PurchReqLine` associata al `case` della richiesta. Acquisisci Unire `PurchReqLine` con `PurchLine` sul campo di riferimento di collegamento (es. `PurchReqLineRefId`). Tipo di evento inferred
	Richiesta Chiusa	L'intera richiesta di acquisto è considerata completa quando tutte le sue voci sono state elaborate in ordini di acquisto o annullate. Questo rappresenta uno stato finale di successo.
Perché è importante Questa attività segna il completamento con successo del ciclo di vita della richiesta. È il punto finale per misurare la durata totale del processo `end-to-end`. Dove trovare Questo stato è tipicamente calcolato o inferito. Si verifica quando tutti i record 'PurchReqLine' associati hanno raggiunto uno stato terminale (ad es. 'Chiuso', 'Annullato'). Acquisisci Derivare questo `evento` verificando se tutti i record figli di `PurchReqLine` per una `PurchReqTable` hanno uno stato finale. Tipo di evento calculated
	Richiesta Creata	Questo `event` segna la creazione iniziale del record della richiesta di acquisto in stato di bozza. Viene catturato identificando il `timestamp` di creazione dell'header della richiesta di acquisto.
Perché è importante Essendo l'inizio del processo, questa attività è essenziale per misurare il tempo complessivo del ciclo di vita della richiesta e analizzare i volumi giornalieri di produzione delle richieste. Dove trovare Questa attività è inferita dal campo 'createdDateTime' nella 'PurchReqTable' per ogni nuovo `Purchase Requisition ID`. Acquisisci Utilizzi il `timestamp` di creazione del record nella PurchReqTable. Tipo di evento inferred
	Richiesta di acquisto approvata	La richiesta ha superato con successo tutte le fasi di approvazione richieste nel `workflow`. Questa attività viene registrata quando l'istanza del `workflow` si conclude con uno stato finale approvato.
Perché è importante Questo è una `milestone` importante, che segna la fine del ciclo di approvazione e l'inizio della fase di `procurement`. È l'`end event` per il KPI 'Tempo di Ciclo di Approvazione della Richiesta'. Dove trovare Catturato esplicitamente dalla `WorkflowTrackingStatusTable` quando il `workflow` è completato. Questo aggiorna anche il campo 'Status' sulla `PurchReqTable` a 'Approvato'. Acquisisci Filtrare per `eventi` di 'Completamento' del `workflow` con stato 'Approvato' o tracciare il cambiamento di stato su `PurchReqTable`. Tipo di evento explicit
	Richiesta Inviata per Approvazione	L'utente invia la richiesta completata, che avvia il `workflow` formale di approvazione. Questa è un'azione esplicita registrata dal motore del `workflow` del sistema.
Perché è importante Questa attività è una `milestone` critica che avvia il ciclo di approvazione. È il punto di partenza per misurare il 'Tempo di Ciclo di Approvazione della Richiesta' e il 'Tasso di Approvazione al Primo Passaggio'. Dove trovare Catturato dalla `WorkflowTrackingStatusTable` o da una tabella di cronologia `workflow` simile, dove un `evento` di 'Invio' viene registrato contro la richiesta d'acquisto. Acquisisci Filtrare i `log` di cronologia del `workflow` per il tipo di `evento` 'Invio' o 'Avvio' legato alla richiesta. Tipo di evento explicit
	Richiesta Rifiutata	La richiesta è stata rifiutata durante il `workflow` di approvazione e non verrà ulteriormente elaborata. Questo rappresenta uno stato di fallimento terminale per la richiesta.
Perché è importante Questo `end event` è critico per analizzare i tassi di rifiuto complessivi e comprendere l'impatto finanziario o operativo delle richieste fallite. Dove trovare Catturato esplicitamente dalla `WorkflowTrackingStatusTable` al completamento del `workflow` con uno stato 'Rifiutato', che aggiorna il campo `status` della `PurchReqTable`. Acquisisci Filtrare per `eventi` di 'Completamento' del `workflow` con stato 'Rifiutato' o tracciare il cambiamento di stato su `PurchReqTable`. Tipo di evento explicit
	Fase di Approvazione Avviata	Un compito di approvazione individuale viene assegnato a un utente o a un gruppo come parte del `workflow`. Questo rappresenta l'inizio di un tempo di attesa o di elaborazione per uno specifico approvatore.
Perché è importante Questa attività è cruciale per l''Analisi dei `Bottleneck` dei Passaggi di Approvazione', consentendo la misurazione dei tempi di coda per fasi di approvazione specifiche. Dove trovare Catturato dalla `WorkflowTrackingStatusTable` quando viene creato e assegnato un nuovo elemento di lavoro per l'istanza del `workflow` della richiesta. Acquisisci Identificare gli `eventi` 'WorkItemCreated' o simili nei `log` di cronologia del `workflow` per la specifica richiesta. Tipo di evento explicit
	Fase di Approvazione Rifiutata	Un approvatore rifiuta il compito assegnato, tipicamente rimandando la richiesta all'originatore per la correzione. Questa è un'azione esplicita registrata dal motore del `workflow`.
Perché è importante Questa attività è fondamentale per calcolare il 'Tasso di Rifiuto delle Richieste' e identificare in quali fasi si verificano più spesso i rifiuti, evidenziando le aree di miglioramento del processo. Dove trovare Registrato esplicitamente nella `WorkflowTrackingStatusTable` quando un utente completa un elemento di lavoro con un esito 'Rifiuta'. Acquisisci Identificare gli `eventi` 'WorkItemCompleted' con esito 'Rifiuta' nei `log` di cronologia del `workflow`. Tipo di evento explicit
	Linea di Richiesta Chiusa	Una singola voce di riga su una richiesta d'acquisto è considerata completamente elaborata. Ciò avviene tipicamente dopo che la riga è stata completamente convertita in un ordine di acquisto.
Perché è importante Fornisce dettagli granulari sull'evasione delle richieste, aiutando a identificare se le richieste sono parzialmente o completamente convertite in ordini di acquisto. Dove trovare Inferito dal campo `status` sulla tabella `PurchReqLine` individuale. Uno stato che indica che è ordinato o ricevuto significherebbe la chiusura. Acquisisci Monitorare il campo `status` sulla tabella `PurchReqLine` per un valore terminale come 'Fatturato' o 'Chiuso'. Tipo di evento inferred
	Richiesta Modificata	Questo `event` si verifica quando un utente richiama una richiesta inviata dal `workflow` per apportare modifiche. L'attività viene tipicamente catturata identificando un'azione di richiamo seguita da una successiva nuova sottomissione.
Perché è importante Il tracciamento delle modifiche è fondamentale per identificare le rielaborazioni, le richieste iniziali poco chiare e le inefficienze di processo. Supporta direttamente la `dashboard` 'Frequenza delle Modifiche delle Richieste'. Dove trovare Può essere inferito dalla cronologia del `workflow` (`WorkflowTrackingStatusTable`) rilevando un'azione di 'Richiamo' o 'Richiesta di modifica'. Può anche essere inferito da modifiche al campo `modifiedDateTime` su `PurchReqTable` dopo l'invio. Acquisisci Rilevare `eventi` di richiamo del `workflow` o modifiche della versione del record tra gli `eventi` di invio. Tipo di evento inferred
	Richiesta Ritirata	Il creatore o un utente autorizzato annulla la richiesta dopo l'invio. Questa azione interrompe il `workflow` e la richiesta.
Perché è importante Il tracciamento dei ritiri aiuta a identificare problemi con la pianificazione della domanda o processi eccessivamente complessi. Questo supporta la `dashboard` 'Insight sui Ritiri delle Richieste'. Dove trovare Questo è inferito da un cambio di stato nella 'PurchReqTable' a 'Annullato' o da un `event` 'Annulla' nella 'WorkflowTrackingStatusTable'. Acquisisci Rilevare il cambiamento di stato a 'Annullato' su `PurchReqTable` o un `evento` di annullamento del `workflow`. Tipo di evento inferred

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i tuoi dati da Microsoft Dynamics 365

Fasi

Accesso all'area di lavoro Gestione dati: acceda a Microsoft Dynamics 365 e vada al menu Workspaces. Selezioni Data management per aprire l'hub centrale delle operazioni di importazione ed esportazione dati.
Creazione di un nuovo progetto di esportazione: nell'area di lavoro Gestione dati, faccia clic sul riquadro Export. Inserisca un Group name univoco, una Description descrittiva e imposti Project category su Project per organizzare le attività di estrazione.
Aggiunta delle entità di dati: aggiunga al progetto le entità di dati standard necessarie. Clicchi su Add entity e cerchi le seguenti, aggiungendole una per una:
- Purchase requisition headers (Testate richieste di acquisto)
- Purchase requisition lines (Righe richieste di acquisto)
- Workflow tracking status table (Tabella stato monitoraggio workflow)
- Workflow work items (Elementi di lavoro del workflow)
- Purchase order lines V2 (Righe ordine di acquisto V2)
Definizione del formato di esportazione: per ogni entità aggiunta, selezioni un Target data format come CSV o Excel. Il formato CSV è generalmente consigliato per prestazioni e compatibilità con gli strumenti di trasformazione dati.
Applicazione dei filtri ai dati: selezioni un'entità e clicchi sul pulsante Filter. Nella scheda Range, specifichi la Legal entity (codice società) per assicurarsi di estrarre i dati dall'unità di business corretta. È inoltre fondamentale aggiungere un filtro temporale sul campo Created date and time dell'entità Purchase requisition headers per limitare il volume dei dati. Consigliamo di iniziare con un periodo di 3-6 mesi.
Esecuzione del job di esportazione: configurate entità e filtri, clicchi su Export nel riquadro azioni. Il sistema creerà un pacchetto di lavoro e avvierà l'elaborazione. Può monitorare l'avanzamento nella sezione Job history.
Download del pacchetto dati: al termine del job, acceda ai dettagli in Job history e clicchi su Download package. Verrà scaricato un file ZIP contenente i file di dati separati per ogni entità.
Trasformazione dei dati grezzi in Event Log: i file esportati rappresentano tabelle di sistema grezze, non un event log finale. Dovrà utilizzare uno strumento esterno come Python, Power Query o una piattaforma ETL per combinare e rimodellare i dati. Ciò include:
- L'unione (join) dei file di testata e di riga.
- L'unione dei dati del workflow alle richieste utilizzando il CorrelationId e il RecId della testata della richiesta di acquisto.
- La trasformazione (pivot) dei cambi di stato e degli eventi del workflow in righe di attività distinte (Requisition Submitted, Approval Step Approved, ecc.).
- La creazione di una nuova riga per ogni attività con i valori corretti di ActivityName, EventTime e PurchaseRequisitionId.
Calcolo e mappatura degli attributi: durante la trasformazione, mappi le colonne sorgente agli attributi richiesti come User e Department. Calcoli gli attributi derivati come RequisitionTotalAmount sommando gli importi delle righe. Imposti un valore statico per SourceSystemId (es. 'D365_F&O') e usi l'ora di esecuzione dello script per LastDataIngestionTimestamp.
Finalizzazione e formattazione dell'output: si assicuri che il file di output finale sia un unico file CSV in cui ogni riga rappresenta un evento del processo. Le colonne devono corrispondere alla struttura richiesta per l'event log, inclusi PurchaseRequisitionId, ActivityName e EventTime.

Configurazione

Autorizzazioni richieste: Gli utenti devono avere un ruolo di sicurezza con autorizzazioni per l'area di lavoro Data management e accesso alle specifiche entità dati in fase di esportazione, come Data management administrator o un ruolo personalizzato simile.
Principali entità dati:
- Purchase requisition headers: Fornisce l'identificatore del caso principale, il timestamp di creazione e lo stato generale.
- Purchase requisition lines: Contiene i dettagli di ogni articolo richiesto, inclusi importi e collegamenti agli ordini di acquisto.
- Workflow tracking status table: La fonte primaria per gli eventi del workflow come invio, approvazione, rifiuto e richiamo.
- Workflow work items: Dettaglia le attività specifiche assegnate agli utenti durante il processo di approvazione.
- Purchase order lines V2: Utilizzato per trovare il timestamp di creazione dell'ordine di acquisto collegato a una riga di richiesta.
Filtro per intervallo di date: È fondamentale applicare un filtro per intervallo di date al campo Created date and time sull'entità Purchase requisition headers. Per un'analisi iniziale, si consiglia un intervallo di 3-6 mesi per bilanciare il volume dei dati e l'approfondimento del processo.
Filtro per codice azienda: Applicare sempre un filtro per la Legal entity per evitare di estrarre dati da aziende non intenzionali o di test. Questo riduce significativamente la dimensione dei dati e migliora le prestazioni del lavoro.
Trasformazione dei dati: Questo metodo richiede un significativo passaggio di post-elaborazione al di fuori di Dynamics 365 per trasformare le esportazioni di entità raw in un event log strutturato. Preparatevi a utilizzare uno strumento di scripting o ETL.

a Query di Esempio config

/*
This is not a single executable query. Instead, it is a configuration manifest for a Dynamics 365 Data Management Framework Export Project.
You must add each entity listed below to the project and select the specified fields for export.
The transformation logic to create the final event log must be applied after exporting these files.
*/

-- Entity 1: Purchase requisition headers
-- Purpose: Captures requisition creation, overall status, and header-level attributes.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    REQUISITIONSTATUS AS RequisitionStatus,
    CREATEDDATETIME AS EventTime_RequisitionCreated,
    MODIFIEDDATETIME AS EventTime_RequisitionClosed, -- Used if status is Closed
    PREPARERPERSONNELNUMBER AS User_Preparer,
    REQUESTERPERSONNELNUMBER AS User_Requester,
    DEFAULTLEDGERDIMENSIONDISPLAYVALUE AS Department, -- Or similar dimension field
    REQUISITIONTOTAL AS RequisitionTotalAmount
FROM PurchaseRequisitionHeaderEntity;

-- Entity 2: Purchase requisition lines
-- Purpose: Provides line-level details, amounts, and links to Purchase Orders.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    LINENUMBER,
    REQUISITIONINGSTATUS AS LineStatus,
    MODIFIEDDATETIME AS EventTime_LineClosed, -- Used if status is Closed
    PURCHASEORDERNUMBER,
    PURCHASEORDERLINENUMBER
FROM PurchaseRequisitionLineEntity;

-- Entity 3: Workflow tracking status table
-- Purpose: The primary source for all workflow-driven activities.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CONTEXT, -- Contains information like step name
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_WorkflowStep,
    TRACKINGSTATUS AS ActivityName, -- (e.g., Submitted, Approved, Rejected, Canceled)
    USERID AS User
FROM WorkflowTrackingStatusTableEntity;

-- Entity 4: Workflow work items
-- Purpose: Captures the start of an approval task assigned to a user.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_ApprovalStepStarted,
    USERID AS User, -- The user assigned the task
    DESCRIPTION AS ApprovalStep
FROM WorkflowWorkItemTableEntity;

-- Entity 5: Purchase order lines V2
-- Purpose: Used to find the creation date of the resulting Purchase Order.
-- Note: Requires joining to PurchaseRequisitionLineEntity on PO/Line number post-export.
SELECT
    PURCHASEORDERNUMBER,
    LINENUMBER,
    CREATEDDATETIME AS EventTime_PurchaseOrderCreated
FROM PurchaseOrderLinesV2Entity;

Fasi

Registrare un'applicazione Azure Active Directory: acceda al portale Azure e registri una nuova applicazione. Questa verrà utilizzata per l'autenticazione con l'API di Dynamics 365. Prenda nota dell'ID applicazione (client) e dell'ID directory (tenant).
Generare un Client Secret: all'interno dell'applicazione registrata in Azure, crei un nuovo segreto client nella sezione 'Certificati e segreti'. Copi il valore del segreto in modo sicuro, poiché non sarà più visibile in seguito.
Concedere i permessi API: nella sezione 'Autorizzazioni API', aggiunga un permesso per 'Dynamics ERP'. Selezioni 'Autorizzazioni delegate' e conceda Financials.ReadWrite.All o un equivalente di sola lettura più restrittivo. Fornisca il consenso dell'amministratore per i permessi.
Installare le librerie Python: verifichi che Python sia installato. Quindi, installi le librerie necessarie tramite pip: pip install requests pandas.
Configurare lo script Python: copi lo script Python fornito in un file, ad esempio extract_d365_requisitions.py. Compili le variabili segnaposto all'inizio dello script: URL di Dynamics 365, ID Tenant, ID Client, Client Secret, l'intervallo di date desiderato e l'ID società.
Comprendere le entità OData: lo script interroga tre entità di dati principali: PurchaseRequisitionHeaders per i dettagli della richiesta, PurchaseRequisitionLines per i dettagli delle righe (inclusa la conversione in ordini d'acquisto) e WorkflowTrackingStatusTable per tutti gli eventi del workflow come invii e approvazioni.
Eseguire lo script: lanci lo script dalla riga di comando: python extract_d365_requisitions.py. Lo script gestirà l'autenticazione, il recupero dei dati per ogni attività e la paginazione delle API in automatico.
Trasformazione dei dati: lo script elabora i dati JSON grezzi dalle chiamate API. Rimodella i dati iterando tra i record e creando una riga distinta per ciascuna delle 12 attività di business, mappando i campi sorgente alle colonne standard dell'event log come PurchaseRequisitionId, ActivityName e EventTime.
Combinare e standardizzare gli eventi: tutti gli eventi generati vengono raccolti in un'unica lista e convertiti in un DataFrame pandas. Lo script aggiunge colonne statiche come SourceSystemId e il LastDataIngestionTimestamp.
Esportare in CSV: il DataFrame finale viene esportato in un file CSV denominato d365_purchase_requisition_log.csv. Questo file è formattato per il caricamento diretto in uno strumento di Process Mining. Verifichi che il file sia codificato in UTF-8.

Configurazione

Prerequisiti: Accesso a una sottoscrizione Azure per registrare un'applicazione. Un ID applicazione (client), Segreto client e ID tenant da Azure Active Directory. L'utente che esegue lo script necessita di credenziali che garantiscono l'accesso agli endpoint dell'API OData di Dynamics 365 Finance and Operations.
Configurazione dell'endpoint API: Lo script richiede l'URL base dell'ambiente Dynamics 365, tipicamente nel formato https://[your-environment-name].operations.dynamics.com.
Intervallo di date: Impostare le variabili START_DATE e END_DATE nello script per definire la finestra di estrazione. Per un'analisi iniziale, si consiglia un periodo di 3-6 mesi per bilanciare il volume dei dati e l'insight.
Filtro azienda: Lo script è configurato per filtrare una specifica entità legale utilizzando la variabile COMPANY_ID. Per estrarre dati per tutte le aziende, potrebbe essere necessario modificare il filtro OData e includere cross-company=true nelle intestazioni della richiesta.
Considerazioni sulle prestazioni: Lo script recupera solo le colonne necessarie per l'event log utilizzando $select nelle query OData, il che migliora le prestazioni. Gestisce anche la paginazione per gestire grandi set di dati senza sovraccaricare l'API. Per carichi storici molto grandi, considerare di eseguire lo script in batch con intervalli di date più piccoli.

a Query di Esempio python

import requests
import pandas as pd
from datetime import datetime, timezone
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Dynamics 365 environment details
D365_URL = class="hl-string">"https://[your-d365-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the data extraction window
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"
COMPANY_ID = class="hl-string">"[YourCompanyLegalEntity]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">"USMF"
OUTPUT_FILENAME = class="hl-string">"d365_purchase_requisition_log.csv"


def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    auth_url = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}/oauth2/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'resource': D365_URL
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

def fetch_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_records = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Accept': class="hl-string">'application/json'
    }
    while entity_url:
        response = requests.get(entity_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        entity_url = data.get(class="hl-string">'@odata.nextLink')
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Acquiring access token...")
    access_token = get_access_token()
    events = []
    last_ingestion_ts = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Purchase Requisition Headers for class="hl-string">'Created' and class="hl-string">'Closed' events
    print(class="hl-string">"Fetching Purchase Requisition Headers...")
    pr_headers_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionHeaders?" 
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}" 
        fclass="hl-string">"&$select=RequisitionNumber,RequisitionStatus,CreatedDateTime,CreatedBy,RequestingDepartmentName,RequisitionTotalAmount,RequisitionUrgencyLevel"
    )
    pr_headers = fetch_data(access_token, pr_headers_url)

    for prh in pr_headers:
        case_id = prh.get(class="hl-string">'RequisitionNumber')
        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        events.append({
            class="hl-string">'PurchaseRequisitionId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'),
            class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
            class="hl-string">'RequisitionStatus': prh.get(class="hl-string">'RequisitionStatus'),
            class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
            class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
            class="hl-string">'ApprovalStep': None,
            class="hl-string">'ProcessingTime': None
        })
        class=class="hl-string">"hl-comment"># Activity: Requisition Closed
        if prh.get(class="hl-string">'RequisitionStatus') == class="hl-string">'Closed':
            class=class="hl-string">"hl-comment"># Note: We need a reliable timestamp for closure. Using CreatedDateTime as a placeholder.
            class=class="hl-string">"hl-comment"># A better source might be the last workflow approval or line closure date.
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Closed',
                class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'), class=class="hl-string">"hl-comment"># Placeholder timestamp
                class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'), class=class="hl-string">"hl-comment"># Placeholder user
                class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
                class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 2. Fetch Workflow History for workflow-related events
    print(class="hl-string">"Fetching Workflow Tracking Status Table...")
    workflow_url = (
        fclass="hl-string">"{D365_URL}/data/WorkflowTrackingStatusTable?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE} and startswith(Context,'PurchReq')"
        fclass="hl-string">"&$select=Context,CreatedDateTime,TrackingType,User,WorkItemSubject"
    )
    workflow_items = fetch_data(access_token, workflow_url)

    for item in workflow_items:
        context_parts = item.get(class="hl-string">'Context', class="hl-string">'').split(class="hl-string">':')
        if len(context_parts) < 2:
            continue
        case_id = context_parts[1].strip()
        tracking_type = item.get(class="hl-string">'TrackingType')
        activity_map = {
            class="hl-string">'Submission': class="hl-string">'Requisition Submitted for Approval',
            class="hl-string">'Started': class="hl-string">'Approval Step Started',
            class="hl-string">'Completion': class="hl-string">'Approval Step Approved',
            class="hl-string">'Rejection': class="hl-string">'Approval Step Rejected',
            class="hl-string">'Cancellation': class="hl-string">'Requisition Withdrawn',
            class="hl-string">'Recall': class="hl-string">'Requisition Amended',
            class="hl-string">'Approved': class="hl-string">'Requisition Approved',
            class="hl-string">'Fault': class="hl-string">'Requisition Rejected'
        }
        activity_name = activity_map.get(tracking_type)
        if activity_name:
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
                class="hl-string">'User': item.get(class="hl-string">'User'),
                class="hl-string">'Department': None, class=class="hl-string">"hl-comment"># Department info is not in this entity
                class="hl-string">'RequisitionStatus': None, class=class="hl-string">"hl-comment"># Status info is not in this entity
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': item.get(class="hl-string">'WorkItemSubject'),
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 3. Fetch Purchase Requisition Lines for PO Creation and Line Closure
    print(class="hl-string">"Fetching Purchase Requisition Lines...")
    pr_lines_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionLines?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"
        fclass="hl-string">"&$select=RequisitionNumber,PurchaseOrderNumber,IsPrepaymentRequired,LineStatus,ModifiedDateTime,ModifiedBy"
    )
    pr_lines = fetch_data(access_token, pr_lines_url)

    for prl in pr_lines:
        case_id = prl.get(class="hl-string">'RequisitionNumber')
        po_number = prl.get(class="hl-string">'PurchaseOrderNumber')
        line_status = prl.get(class="hl-string">'LineStatus')
        
        class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
        if po_number:
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': None,
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': fclass="hl-string">"PO: {po_number}",
                class="hl-string">'ProcessingTime': None
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Line Closed
        if line_status == class="hl-string">'Closed':
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Line Closed',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    if not events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    class=class="hl-string">"hl-comment"># 4. Create and format the DataFrame
    print(class="hl-string">"Formatting data...")
    df = pd.DataFrame(events)
    df[class="hl-string">'SourceSystemId'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataIngestionTimestamp'] = last_ingestion_ts

    class=class="hl-string">"hl-comment"># Fill forward missing data within each case
    df = df.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])
    df[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']] = \
        df.groupby(class="hl-string">'PurchaseRequisitionId')[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']].ffill().bfill()

    class=class="hl-string">"hl-comment"># Ensure required columns exist and are in order
    final_columns = [
        class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'SourceSystemId',
        class="hl-string">'LastDataIngestionTimestamp',
        class="hl-string">'User',
        class="hl-string">'Department',
        class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionTotalAmount',
        class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalStep',
        class="hl-string">'ProcessingTime'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[final_columns]

    class=class="hl-string">"hl-comment"># 5. Save to CSV
    df.to_csv(OUTPUT_FILENAME, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {OUTPUT_FILENAME}")

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

Fasi

Accesso all'area di lavoro Gestione dati: acceda a Microsoft Dynamics 365 e vada al menu Workspaces. Selezioni Data management per aprire l'hub centrale delle operazioni di importazione ed esportazione dati.
Creazione di un nuovo progetto di esportazione: nell'area di lavoro Gestione dati, faccia clic sul riquadro Export. Inserisca un Group name univoco, una Description descrittiva e imposti Project category su Project per organizzare le attività di estrazione.
Aggiunta delle entità di dati: aggiunga al progetto le entità di dati standard necessarie. Clicchi su Add entity e cerchi le seguenti, aggiungendole una per una:
- Purchase requisition headers (Testate richieste di acquisto)
- Purchase requisition lines (Righe richieste di acquisto)
- Workflow tracking status table (Tabella stato monitoraggio workflow)
- Workflow work items (Elementi di lavoro del workflow)
- Purchase order lines V2 (Righe ordine di acquisto V2)
Definizione del formato di esportazione: per ogni entità aggiunta, selezioni un Target data format come CSV o Excel. Il formato CSV è generalmente consigliato per prestazioni e compatibilità con gli strumenti di trasformazione dati.
Applicazione dei filtri ai dati: selezioni un'entità e clicchi sul pulsante Filter. Nella scheda Range, specifichi la Legal entity (codice società) per assicurarsi di estrarre i dati dall'unità di business corretta. È inoltre fondamentale aggiungere un filtro temporale sul campo Created date and time dell'entità Purchase requisition headers per limitare il volume dei dati. Consigliamo di iniziare con un periodo di 3-6 mesi.
Esecuzione del job di esportazione: configurate entità e filtri, clicchi su Export nel riquadro azioni. Il sistema creerà un pacchetto di lavoro e avvierà l'elaborazione. Può monitorare l'avanzamento nella sezione Job history.
Download del pacchetto dati: al termine del job, acceda ai dettagli in Job history e clicchi su Download package. Verrà scaricato un file ZIP contenente i file di dati separati per ogni entità.
Trasformazione dei dati grezzi in Event Log: i file esportati rappresentano tabelle di sistema grezze, non un event log finale. Dovrà utilizzare uno strumento esterno come Python, Power Query o una piattaforma ETL per combinare e rimodellare i dati. Ciò include:
- L'unione (join) dei file di testata e di riga.
- L'unione dei dati del workflow alle richieste utilizzando il CorrelationId e il RecId della testata della richiesta di acquisto.
- La trasformazione (pivot) dei cambi di stato e degli eventi del workflow in righe di attività distinte (Requisition Submitted, Approval Step Approved, ecc.).
- La creazione di una nuova riga per ogni attività con i valori corretti di ActivityName, EventTime e PurchaseRequisitionId.
Calcolo e mappatura degli attributi: durante la trasformazione, mappi le colonne sorgente agli attributi richiesti come User e Department. Calcoli gli attributi derivati come RequisitionTotalAmount sommando gli importi delle righe. Imposti un valore statico per SourceSystemId (es. 'D365_F&O') e usi l'ora di esecuzione dello script per LastDataIngestionTimestamp.
Finalizzazione e formattazione dell'output: si assicuri che il file di output finale sia un unico file CSV in cui ogni riga rappresenta un evento del processo. Le colonne devono corrispondere alla struttura richiesta per l'event log, inclusi PurchaseRequisitionId, ActivityName e EventTime.

Configurazione

Autorizzazioni richieste: Gli utenti devono avere un ruolo di sicurezza con autorizzazioni per l'area di lavoro Data management e accesso alle specifiche entità dati in fase di esportazione, come Data management administrator o un ruolo personalizzato simile.
Principali entità dati:
- Purchase requisition headers: Fornisce l'identificatore del caso principale, il timestamp di creazione e lo stato generale.
- Purchase requisition lines: Contiene i dettagli di ogni articolo richiesto, inclusi importi e collegamenti agli ordini di acquisto.
- Workflow tracking status table: La fonte primaria per gli eventi del workflow come invio, approvazione, rifiuto e richiamo.
- Workflow work items: Dettaglia le attività specifiche assegnate agli utenti durante il processo di approvazione.
- Purchase order lines V2: Utilizzato per trovare il timestamp di creazione dell'ordine di acquisto collegato a una riga di richiesta.
Filtro per intervallo di date: È fondamentale applicare un filtro per intervallo di date al campo Created date and time sull'entità Purchase requisition headers. Per un'analisi iniziale, si consiglia un intervallo di 3-6 mesi per bilanciare il volume dei dati e l'approfondimento del processo.
Filtro per codice azienda: Applicare sempre un filtro per la Legal entity per evitare di estrarre dati da aziende non intenzionali o di test. Questo riduce significativamente la dimensione dei dati e migliora le prestazioni del lavoro.
Trasformazione dei dati: Questo metodo richiede un significativo passaggio di post-elaborazione al di fuori di Dynamics 365 per trasformare le esportazioni di entità raw in un event log strutturato. Preparatevi a utilizzare uno strumento di scripting o ETL.

a Query di Esempio config

/*
This is not a single executable query. Instead, it is a configuration manifest for a Dynamics 365 Data Management Framework Export Project.
You must add each entity listed below to the project and select the specified fields for export.
The transformation logic to create the final event log must be applied after exporting these files.
*/

-- Entity 1: Purchase requisition headers
-- Purpose: Captures requisition creation, overall status, and header-level attributes.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    REQUISITIONSTATUS AS RequisitionStatus,
    CREATEDDATETIME AS EventTime_RequisitionCreated,
    MODIFIEDDATETIME AS EventTime_RequisitionClosed, -- Used if status is Closed
    PREPARERPERSONNELNUMBER AS User_Preparer,
    REQUESTERPERSONNELNUMBER AS User_Requester,
    DEFAULTLEDGERDIMENSIONDISPLAYVALUE AS Department, -- Or similar dimension field
    REQUISITIONTOTAL AS RequisitionTotalAmount
FROM PurchaseRequisitionHeaderEntity;

-- Entity 2: Purchase requisition lines
-- Purpose: Provides line-level details, amounts, and links to Purchase Orders.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    LINENUMBER,
    REQUISITIONINGSTATUS AS LineStatus,
    MODIFIEDDATETIME AS EventTime_LineClosed, -- Used if status is Closed
    PURCHASEORDERNUMBER,
    PURCHASEORDERLINENUMBER
FROM PurchaseRequisitionLineEntity;

-- Entity 3: Workflow tracking status table
-- Purpose: The primary source for all workflow-driven activities.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CONTEXT, -- Contains information like step name
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_WorkflowStep,
    TRACKINGSTATUS AS ActivityName, -- (e.g., Submitted, Approved, Rejected, Canceled)
    USERID AS User
FROM WorkflowTrackingStatusTableEntity;

-- Entity 4: Workflow work items
-- Purpose: Captures the start of an approval task assigned to a user.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_ApprovalStepStarted,
    USERID AS User, -- The user assigned the task
    DESCRIPTION AS ApprovalStep
FROM WorkflowWorkItemTableEntity;

-- Entity 5: Purchase order lines V2
-- Purpose: Used to find the creation date of the resulting Purchase Order.
-- Note: Requires joining to PurchaseRequisitionLineEntity on PO/Line number post-export.
SELECT
    PURCHASEORDERNUMBER,
    LINENUMBER,
    CREATEDDATETIME AS EventTime_PurchaseOrderCreated
FROM PurchaseOrderLinesV2Entity;

Il Suo template per i dati delle richieste Purchase to Pay

Il Suo template per i dati delle richieste Purchase to Pay

Attributi di Dall'Acquisto al Pagamento - Richiesta

Attività di Dall'Acquisto al Pagamento - Richiesta

Guide all'Estrazione

Esportazione dal Framework di Gestione Dati di Dynamics 365

Fasi

Configurazione

a Query di Esempio config

Script Python che utilizza l'API REST OData di Dynamics 365

Fasi

Configurazione

a Query di Esempio python

Estrazione tramite Connettore Nativo Microsoft Power BI

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Ottimizza il Processo Dall'Acquisto al Pagamento - Richiesta per Approvazioni più Veloci Ora

Il Suo template per i dati delle richieste Purchase to Pay

Il Suo template per i dati delle richieste Purchase to Pay

Attributi di Dall'Acquisto al Pagamento - Richiesta

Attività di Dall'Acquisto al Pagamento - Richiesta

Guide all'Estrazione

Esportazione dal Framework di Gestione Dati di Dynamics 365

Fasi

Configurazione

a Query di Esempio config

Script Python che utilizza l'API REST OData di Dynamics 365

Fasi

Configurazione

a Query di Esempio python

Estrazione tramite Connettore Nativo Microsoft Power BI

Fasi

Configurazione

a Query di Esempio config

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Ottimizza il Processo Dall'Acquisto al Pagamento - Richiesta per Approvazioni più Veloci Ora