> Miglioramento continuo dei processi > Purchase to Pay Requisition > Microsoft Dynamics 365 > Template dei dati

Il Suo Template dei dati Purchase to Pay - Richiesta

Microsoft Dynamics 365

Purchase to Pay - Requisition: attributi (17) Purchase to Pay - Requisition: attività (12) Guide all'estrazione (3)

Il Suo Template dei dati Purchase to Pay - Richiesta

Questo Template descrive gli attributi principali da raccogliere e le attività essenziali da monitorare, consentendo un'analisi approfondita del processo di richiesta. Fornisce inoltre indicazioni pratiche per l'estrazione di questi dati, aiutandoLa a preparare in modo efficiente l'Event Log per un'analisi dettagliata.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l'estrazione

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

Scarica il Template

Purchase to Pay - Requisition: attributi

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

5 Obbligatorio 6 Consigliato 6 Facoltativo

	Nome	Descrizione
	ID della richiesta di acquisto PurchaseRequisitionId	L'identificatore univoco di una richiesta di acquisto, utilizzato come identificatore principale del caso.
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, viene tracciato tramite questo ID univoco. Nel process mining, questo attributo è fondamentale per ricostruire il percorso end-to-end di ogni richiesta. Consente di analizzare le varianti di processo, i tempi di ciclo e la Conformità dei 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 ogni richiesta. Dove reperirlo In genere è la chiave primaria nella tabella principale dell'intestazione delle richieste di acquisto, come PurchReqTable in Microsoft Dynamics 365. Esempi PR-001254PR-001255PR-001256
	Nome dell'attività ActivityName	Il nome dello specifico evento o passaggio aziendale che si è verificato nel processo di richiesta.
Descrizione Questo attributo registra il nome di ogni attività eseguita durante il ciclo di vita della richiesta di acquisto. Tra gli esempi figurano 'Requisition Created', 'Approval Step Approved' e 'Purchase Order Created'. Queste attività costituiscono i nodi della mappa di processo individuata. L'analisi della sequenza, della frequenza e della durata tra queste attività è il fulcro del process mining. Aiuta a identificare colli di bottiglia, cicli di rilavorazione e deviazioni dal flusso di processo standard, fornendo informazioni sulle inefficienze operative. Perché è importante Questo attributo definisce i passaggi nella mappa di processo, rendendo possibile visualizzare, analizzare e comprendere il Workflow delle richieste. Dove reperirlo In genere viene ricavato dai log delle variazioni di stato, dalle tabelle dello storico del Workflow o da tabelle di eventi specifiche all'interno di Microsoft Dynamics 365, come WorkflowTrackingStatusTable. Esempi Richiesta inviata per l'approvazionePassaggio di approvazione approvatoRichiesta modificata
	Ora dell'evento EventTime	Il timestamp preciso in cui si è verificata una specifica attività o un evento.
Descrizione L'ora dell'evento, ovvero il timestamp, registra la data e l'ora in cui un evento aziendale è stato registrato nel sistema. Costituisce la base temporale di tutte le analisi di processo basate sul tempo. Questo attributo è fondamentale per calcolare tempi di ciclo, durate e tempi di attesa tra le attività. Consente di analizzare le prestazioni del processo, identificare i colli di bottiglia e monitorare la Conformità agli SLA. Timestamp accurati sono essenziali per un'analisi di process mining affidabile. Perché è importante Fornisce l'ordine cronologico degli eventi, necessario per calcolare le durate del processo, identificare i colli di bottiglia e analizzare le prestazioni nel tempo. Dove reperirlo Si trova nelle tabelle dello storico del Workflow o nei log dei documenti, spesso come campo 'CreatedDateTime' o 'ModifiedDateTime' associato a ogni variazione 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 riferimento da cui sono stati estratti i dati.
Descrizione Questo attributo identifica il sistema di origine da cui provengono i dati degli eventi. In questo contesto sarebbe 'Microsoft Dynamics 365'. Negli ambienti con più sistemi integrati, questo campo è fondamentale per la tracciabilità e il contesto dei dati. Nell'analisi aiuta a distinguere i processi che possono estendersi su più sistemi o a confermare che i dati provengono da un'unica fonte autorevole. È importante per la convalida dei dati e per garantire che l'analisi si basi sul dataset corretto. Perché è importante Fornisce il contesto sull'origine dei dati, fondamentale per la governance e la convalida dei dati, nonché negli ambienti in cui sono integrati più sistemi. Dove reperirlo Si tratta di un valore statico, 'Microsoft Dynamics 365', aggiunto durante il processo di estrazione e trasformazione dei dati. Esempi Microsoft Dynamics 365 F&OD365MSD365
	Ultimo aggiornamento dei dati LastDataIngestionTimestamp	Il timestamp in cui i dati sono stati estratti e caricati per l'ultima volta nello strumento di process mining.
Descrizione Questo attributo indica l'aggiornamento dei dati analizzati. Mostra la data e l'ora dell'aggiornamento più recente dei dati provenienti dal sistema di origine. Non è un campo di Dynamics 365, ma metadati aggiunti durante l'acquisizione dei dati. Questo timestamp è fondamentale per consentire agli utenti di comprendere l'attualità delle informazioni. Aiuta a capire se si stanno esaminando dati in tempo reale o un'istantanea relativa a uno specifico momento, un elemento che influisce sulla rilevanza delle conclusioni. Perché è importante Informa gli utenti sull'aggiornamento dei dati, assicurando che comprendano l'intervallo temporale dell'analisi e la rilevanza delle informazioni ottenute. Dove reperirlo Questo valore viene generato e aggiunto al dataset durante il processo di acquisizione dei dati o di ETL. Esempi 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Fase di approvazione ApprovalStep	Il nome o la fase di una specifica fase di approvazione nel Workflow.
Descrizione Questo attributo identifica la fase specifica del Workflow di approvazione, ad esempio «Approvazione del responsabile» o «Approvazione dell'ufficio finanziario». Fornisce un livello di dettaglio maggiore rispetto al nome generico dell'attività. Questo attributo è essenziale per l'«Analisi dei colli di bottiglia nelle fasi di approvazione». Monitorando il tempo trascorso in ciascuna fase di approvazione, è possibile individuare con precisione le fasi che causano ritardi nel processo complessivo. In questo modo è possibile definire interventi mirati per migliorare l'efficienza del Workflow. Perché è importante Consente un'analisi dettagliata del Workflow di approvazione, rendendo possibile l'identificazione delle fasi specifiche che causano colli di bottiglia. Dove reperirlo Queste informazioni sono contenute nelle tabelle della cronologia del Workflow, come WorkflowTrackingStatusTable, che descrive ogni fase del Workflow configurato. Esempi Approvazione del responsabileApprovazione del responsabile di repartoRevisione Finance
	Importo totale della richiesta RequisitionTotalAmount	Il valore monetario complessivo della richiesta di acquisto.
Descrizione Questo attributo acquisisce il valore totale di tutte le righe di una richiesta di acquisto. L'importo influenza spesso la complessità del Workflow di approvazione, poiché le richieste di valore più elevato richiedono un numero maggiore di passaggi di approvazione. Nell'analisi del processo, questo attributo è essenziale per filtrare e analizzare i casi in base al valore. Aiuta a rispondere a domande come: 'Le richieste di valore elevato richiedono più tempo per essere approvate?' oppure 'Qual è il valore delle richieste attualmente bloccate nel processo?'. In questo modo aggiunge una dimensione finanziaria alla valutazione delle prestazioni del processo. Perché è importante Aggiunge una dimensione finanziaria all'analisi, consentendo di dare priorità ai casi di valore elevato e di comprendere in che modo il valore monetario influisce sul comportamento del processo. Dove reperirlo Questo valore si trova generalmente nella tabella dell'intestazione della richiesta di acquisto oppure viene calcolato come somma degli importi delle righe nella tabella delle righe della richiesta di acquisto, PurchReqLine. Esempi 1500.0025000.50500.75
	Livello di urgenza UrgencyLevel	Una classificazione dell'urgenza della richiesta, ad esempio «Alta», «Media» o «Bassa».
Descrizione Il livello di urgenza, o priorità, indica con quale rapidità sono necessari i beni o i servizi richiesti. Questo attributo viene spesso utilizzato per influenzare il percorso di approvazione o per stabilire la priorità del lavoro degli approvatori. L'analisi di questo attributo aiuta a determinare se il sistema di priorità è efficace. Per esempio, è possibile confrontare i tempi di ciclo delle richieste con urgenza «Alta» con quelli delle richieste con urgenza «Bassa». Se non emerge una differenza significativa, ciò può indicare che il campo della priorità viene ignorato o utilizzato in modo improprio, fornendo un'indicazione importante per la Dashboard «Analisi dell'impatto del livello di urgenza». Perché è importante Aiuta a valutare se le impostazioni di priorità accelerano effettivamente le richieste critiche e fa emergere possibili utilizzi impropri della classificazione dell'urgenza. Dove reperirlo Potrebbe trattarsi di un campo standard o personalizzato di PurchReqTable. La sua presenza e il suo nome possono variare in base alla configurazione del sistema. Esempi AltaMediaBassa
	Reparto Department	Il reparto del richiedente o il centro di costo associato alla richiesta.
Descrizione Questo attributo specifica il reparto aziendale o il centro di costo che ha avviato la richiesta di acquisto, ad esempio 'Marketing', 'IT' o 'Operations'. Queste informazioni fanno generalmente parte dell'intestazione della richiesta. Segmentare il processo per reparto è fondamentale per l'analisi comparativa. Consente di vedere quali reparti presentano i tempi di ciclo più lunghi, i tassi di rifiuto più elevati o il maggior numero di modifiche. Queste informazioni aiutano ad adattare i miglioramenti del processo alle esigenze specifiche di ciascun reparto. Perché è importante Consente di filtrare e confrontare le prestazioni del processo tra diverse unità aziendali, facendo emergere schemi, colli di bottiglia o inefficienze specifici dei reparti. Dove reperirlo Queste informazioni sono spesso memorizzate nell'intestazione della richiesta di acquisto, PurchReqTable, e collegate alla configurazione delle dimensioni finanziarie in Dynamics 365. Esempi Reparto ITFinanzaOperazioni
	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 un determinato momento, ad esempio 'In Review', 'Approved', 'Rejected' o 'Closed'. 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 'Rejected' o 'Withdrawn' 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 esito chiaro per ogni caso, consentendo di analizzare i tassi di approvazione, rifiuto e ritiro, che sono indicatori chiave delle prestazioni. Dove reperirlo Il campo di stato si trova generalmente nella tabella dell'intestazione della richiesta di acquisto, PurchReqTable, e spesso si chiama 'Status' o 'PurchReqStatus'. Esempi ApprovatoIn revisioneRifiutatoBozza
	Utente User	L'ID o il nome dell'utente che ha eseguito l'attività.
Descrizione Questo attributo identifica il dipendente o l'utente di sistema responsabile dell'esecuzione di uno specifico passaggio del processo, come l'invio di una richiesta o l'approvazione di una richiesta. Può essere un ID utente, il nome completo o un indirizzo e-mail. L'analisi delle attività per utente aiuta a identificare esigenze formative, persone o team con prestazioni elevate e la distribuzione dei carichi di lavoro. È inoltre essenziale per l'analisi della Conformità, ad esempio per la segregazione dei compiti, e per comprendere come i diversi ruoli interagiscono con il processo. Perché è importante Consente di analizzare il comportamento, il carico di lavoro e le prestazioni specifici degli utenti, elementi fondamentali per la gestione delle risorse e l'identificazione delle opportunità formative. Dove reperirlo In genere si trova nelle tabelle dello storico del Workflow, ad esempio WorkflowTrackingStatusTable, o nelle tabelle delle transazioni, come PurchReqTable, collegate a una tabella degli utenti, ad esempio UserInfo. Esempi j.smitha.joness.patel
	Approvata al primo passaggio IsFirstPass	Un indicatore che segnala se una richiesta è stata approvata senza modifiche o rifiuti precedenti.
Descrizione Si tratta di un attributo booleano calcolato che assume il valore «true» se il percorso della richiesta verso l'approvazione non include attività «Richiesta modificata» o «Fase di approvazione rifiutata». In caso contrario, assume il valore «false». Questo attributo supporta direttamente il KPI «Tasso di approvazione delle richieste al primo passaggio». Semplifica l'analisi dell'efficienza del processo fornendo un indicatore chiaro, a livello di caso, delle rilavorazioni. Un tasso ridotto di approvazioni al primo passaggio evidenzia problemi nella 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 casi che hanno richiesto rilavorazioni e supportando i KPI incentrati sul tasso di correttezza al primo tentativo. Dove reperirlo È un attributo calcolato. Richiede l'analisi dell'intera sequenza di attività di ciascun caso durante la trasformazione dei dati, per verificare l'assenza di attività di rilavorazione prima dell'approvazione. Esempi truefalse
	Gruppo di approvazione 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 assegnata alla gestione di una specifica attività di approvazione, ad esempio «Approvatori dell'ufficio finanziario» o «Responsabili IT». L'analisi delle prestazioni del processo per gruppo di approvazione è fondamentale per comprendere la distribuzione del carico di lavoro e individuare i gruppi che potrebbero disporre di risorse insufficienti o necessitare di ulteriore formazione. Supporta direttamente la Dashboard «Analisi dei colli di bottiglia nelle fasi di approvazione», consentendo di suddividere le prestazioni in base ai team responsabili delle approvazioni. Perché è importante Aiuta a individuare le differenze di prestazioni tra i team di approvazione, evidenziando possibili vincoli di risorse o esigenze formative all'interno di gruppi specifici. Dove reperirlo Queste informazioni fanno parte della cronologia del Workflow, ad esempio WorkflowTrackingStatusTable, che registra l'utente o il gruppo di utenti assegnato a ciascuna attività. Esempi Approvatori FinanceResponsabili ITAlta dirigenza
	Numero dell'ordine di acquisto PurchaseOrderNumber	L'identificativo dell'ordine di acquisto creato a partire dalla richiesta.
Descrizione Questo attributo memorizza l'ID univoco dell'ordine di acquisto generato da una richiesta di acquisto approvata. Funge da collegamento tra il processo di richiesta e il successivo processo di approvvigionamento. Il monitoraggio di questo numero è essenziale per analizzare il «Tempo di conversione da richiesta a ordine di acquisto». Conferma che una richiesta è passata correttamente alla fase successiva del ciclo Purchase-to-Pay e consente un'analisi end-to-end che comprende sia le richieste sia gli ordini di acquisto. Perché è importante Collega la richiesta al successivo ordine di acquisto, consentendo di analizzare la conversione da richiesta a ordine di acquisto e di collegare diverse fasi del processo P2P. Dove reperirlo Queste informazioni si trovano generalmente nella tabella delle righe della richiesta di acquisto, PurchReqLine, dopo la creazione di un ordine di acquisto, con collegamento a PurchTable. Esempi PO-000987PO-000988PO-000989
	Numero di modifiche AmendmentCount	Il numero totale di volte in cui una richiesta è stata modificata.
Descrizione Si tratta di un attributo numerico calcolato che conta le occorrenze dell'attività «Richiesta modificata» per ciascun caso di richiesta di acquisto. Questo attributo è essenziale per la Dashboard «Frequenza delle modifiche alle richieste» e per il KPI «Rapporto delle modifiche alle richieste». Quantifica la rilavorazione per caso, rendendo semplice individuare le richieste, i reparti o gli utenti associati a livelli elevati di modifiche e inefficienza. In questo modo è possibile concentrare gli interventi sul miglioramento della qualità delle richieste iniziali. Perché è importante Quantifica la rilavorazione all'interno di un caso, rendendo semplice misurare e analizzare la frequenza delle modifiche e il loro impatto sull'efficienza del processo. Dove reperirlo È un attributo calcolato. Viene derivato durante la trasformazione dei dati contando le attività «Richiesta modificata» per ogni PurchaseRequisitionId univoco. Esempi 013
	Percorso del Workflow di approvazione ApprovalWorkflowPath	Una rappresentazione della sequenza delle fasi di approvazione eseguite.
Descrizione Questo attributo è un campo derivato che concatena la sequenza delle fasi di approvazione di una determinata richiesta, ad esempio «Approvazione del responsabile -> Approvazione del responsabile di funzione -> Approvazione dell'ufficio finanziario». Riassume efficacemente la variante di processo del sottoprocesso di approvazione. È fondamentale per la Dashboard «Monitoraggio delle deviazioni di Conformità». Confrontando il percorso effettivo del Workflow con un percorso standard o previsto, è possibile segnalare facilmente i flussi non conformi o insoliti, che possono rappresentare violazioni delle policy o rischi operativi. Perché è importante Semplifica l'analisi della Conformità fornendo una rappresentazione testuale chiara della variante di processo, così da individuare facilmente le deviazioni dalle procedure standard. Dove reperirlo 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 Responsabile -> DirettoreResponsabile -> Direttore -> VP FinanceManager → Approvato automaticamente
	Valuta Currency	Il codice valuta dell'importo della richiesta.
Descrizione Questo attributo specifica la valuta, ad esempio USD, EUR o GBP, nella quale è espresso l'importo totale della richiesta. È fondamentale per l'analisi finanziaria, soprattutto nelle organizzazioni multinazionali che gestiscono più valute. L'utilizzo dell'attributo valuta consente di gestire e aggregare correttamente i dati finanziari. Garantisce che i valori monetari siano interpretati correttamente e permette di convertirli in una valuta comune, così da ottenere report accurati e confrontare diverse aree geografiche o unità aziendali. Perché è importante Fornisce il contesto necessario per gli attributi finanziari, garantendo un'interpretazione e un'aggregazione accurate dei valori monetari negli ambienti multi-valuta. Dove reperirlo Questo campo si trova generalmente nella tabella di intestazione delle richieste di acquisto, PurchReqTable, insieme ai campi relativi agli importi. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Purchase to Pay - Requisition: attività

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

7 Consigliato 5 Facoltativo

	Attività	Descrizione
	Ordine di acquisto creato	Una riga di richiesta di acquisto approvata viene convertita in una riga d'ordine di acquisto, segnando il passaggio al team di approvvigionamento. L'evento viene acquisito collegando la riga della richiesta alla riga dell'ordine di acquisto.
Perché è importante Questa è una tappa fondamentale che collega la richiesta al processo di approvvigionamento a valle. È essenziale per misurare il KPI 'Requisition to PO Conversion Time'. Dove reperirlo Viene dedotto individuando nella tabella 'PurchLine' un record che fa riferimento all'ID di una 'PurchReqLine' associata al caso della richiesta. Acquisizione Esegua il join tra PurchReqLine e PurchLine utilizzando il campo di riferimento che li collega, ad esempio PurchReqLineRefId. Tipo di evento inferred
	Passaggio di approvazione approvato	L'approvatore completa l'attività assegnata, approvando la richiesta per la fase di processo di sua competenza. La richiesta passa così al passaggio successivo o all'approvazione finale.
Perché è importante Misura il tempo di elaborazione di ogni fase di approvazione e aiuta a individuare le parti più efficienti del Workflow. È un elemento fondamentale dell'analisi delle varianti. Dove reperirlo Viene registrato esplicitamente in 'WorkflowTrackingStatusTable' quando un utente completa un elemento di lavoro con esito 'Approve'. Acquisizione Individui nei log dello storico del Workflow gli eventi 'WorkItemCompleted' con esito 'Approve'. Tipo di evento explicit
	Richiesta approvata	La richiesta ha superato con successo tutti i passaggi di approvazione richiesti dal Workflow. Questa attività viene acquisita quando l'istanza Workflow termina con uno stato finale di approvazione.
Perché è importante Si tratta di una tappa fondamentale, che segna la fine del ciclo di approvazione e l'inizio della fase di approvvigionamento. È l'evento finale per il KPI 'Requisition Approval Cycle Time'. Dove reperirlo Viene acquisita esplicitamente da 'WorkflowTrackingStatusTable' al completamento del Workflow. Questo aggiorna inoltre il campo 'Status' di 'PurchReqTable' impostandolo su 'Approved'. Acquisizione Filtri gli eventi di 'Completion' del Workflow con stato 'Approved' oppure monitora la variazione di stato in PurchReqTable. Tipo di evento explicit
	Richiesta chiusa	L'intera richiesta di acquisto è considerata completata, poiché tutte le sue righe sono state trasformate in ordini di acquisto o annullate. Si tratta di uno stato finale positivo.
Perché è importante Questa attività segna il completamento positivo del ciclo di vita della richiesta. È il punto finale per misurare la durata complessiva del processo end-to-end. Dove reperirlo Questo stato viene generalmente calcolato o dedotto. Si verifica quando tutti i record 'PurchReqLine' associati hanno raggiunto uno stato terminale, ad esempio 'Closed' o 'Cancelled'. Acquisizione Derivi questo evento verificando che tutti i record PurchReqLine secondari di un PurchReqTable abbiano raggiunto uno stato finale. Tipo di evento calculated
	Richiesta creata	Questo evento indica la creazione iniziale del record della richiesta di acquisto in stato di bozza. Viene rilevato identificando il timestamp di creazione dell'intestazione della richiesta di acquisto.
Perché è importante In quanto punto di avvio del processo, questa attività è essenziale per misurare la durata complessiva del ciclo di vita della richiesta e analizzare i volumi giornalieri di richieste gestite. Dove reperirlo Questa attività viene dedotta dal campo 'createdDateTime' di 'PurchReqTable' per ogni nuovo Purchase Requisition ID. Acquisizione Utilizzi il timestamp di creazione del record in PurchReqTable. Tipo di evento inferred
	Richiesta inviata per l'approvazione	L'utente invia la richiesta completata, avviando il Workflow formale di approvazione. Si tratta di un'azione esplicita registrata dal motore Workflow del sistema.
Perché è importante Questa attività è una tappa fondamentale che avvia il ciclo di approvazione. Costituisce il punto di partenza per misurare il 'Requisition Approval Cycle Time' e il 'First-Pass Approval Rate'. Dove reperirlo Viene acquisita da 'WorkflowTrackingStatusTable' o da una tabella simile dello storico del Workflow, in cui un evento 'Submission' viene registrato per la richiesta di acquisto. Acquisizione Filtri i log dello storico del Workflow per individuare il tipo di evento 'Submission' o 'Start' associato alla richiesta. Tipo di evento explicit
	Richiesta rifiutata	La richiesta è stata rifiutata durante il Workflow di approvazione e non verrà elaborata ulteriormente. Rappresenta uno stato terminale di esito negativo per la richiesta.
Perché è importante Questo evento finale è fondamentale per analizzare i tassi complessivi di rifiuto e comprendere l'impatto finanziario o operativo delle richieste non andate a buon fine. Dove reperirlo Viene acquisito esplicitamente da 'WorkflowTrackingStatusTable' al completamento del Workflow con stato 'Rejected', che aggiorna il campo di stato di 'PurchReqTable'. Acquisizione Filtri gli eventi di 'Completion' del Workflow con stato 'Rejected' oppure monitora la variazione di stato in PurchReqTable. Tipo di evento explicit
	Passaggio di approvazione avviato	Un'attività di approvazione individuale viene assegnata a un utente o a un gruppo nell'ambito del Workflow. Questo rappresenta l'inizio del tempo di attesa o di elaborazione per uno specifico approvatore.
Perché è importante Questa attività è fondamentale per la 'Approval Step Bottleneck Analysis', perché consente di misurare i tempi di coda nelle singole fasi di approvazione. Dove reperirlo Viene acquisita da 'WorkflowTrackingStatusTable' quando viene creato e assegnato un nuovo elemento di lavoro per l'istanza Workflow della richiesta. Acquisizione Individui nei log dello storico del Workflow gli eventi 'WorkItemCreated' o eventi analoghi relativi alla richiesta specifica. Tipo di evento explicit
	Passaggio di approvazione rifiutato	L'approvatore rifiuta l'attività assegnata, rimandando generalmente la richiesta al richiedente per la correzione. Si tratta di un'azione esplicita registrata dal motore Workflow.
Perché è importante Questa attività è fondamentale per calcolare il 'Requisition Rejection Rate' e identificare le fasi in cui i rifiuti si verificano più spesso, evidenziando le aree da migliorare. Dove reperirlo Viene registrato esplicitamente in 'WorkflowTrackingStatusTable' quando un utente completa un elemento di lavoro con esito 'Reject'. Acquisizione Individui nei log dello storico del Workflow gli eventi 'WorkItemCompleted' con esito 'Reject'. Tipo di evento explicit
	Richiesta modificata	Questo evento si verifica quando un utente richiama dal Workflow una richiesta inviata per apportare modifiche. L'attività viene generalmente rilevata identificando un'azione di richiamo seguita da un nuovo invio.
Perché è importante Monitorare le modifiche è fondamentale per identificare rilavorazioni, richieste iniziali poco chiare e inefficienze del processo. Questo supporta la Dashboard 'Requisition Amendment Frequency'. Dove reperirlo Può essere dedotto dallo storico del Workflow ('WorkflowTrackingStatusTable') rilevando un'azione 'Recall' o 'RequestChange'. Può inoltre essere dedotto dalle modifiche al campo 'modifiedDateTime' di 'PurchReqTable' successive all'invio. Acquisizione Rilevi gli eventi di richiamo del Workflow o le variazioni di versione del record tra un invio e l'altro. Tipo di evento inferred
	Richiesta ritirata	Il creatore o un utente autorizzato annulla la richiesta dopo il suo invio. Questa azione termina il Workflow e la richiesta.
Perché è importante Monitorare i ritiri aiuta a identificare problemi nella pianificazione della domanda o processi eccessivamente complessi. Questo supporta la Dashboard 'Requisition Withdrawal Insights'. Dove reperirlo Viene dedotto da una variazione dello stato di 'PurchReqTable' a 'Cancelled' oppure da un evento 'Cancel' in 'WorkflowTrackingStatusTable'. Acquisizione Rilevi la variazione dello stato a 'Cancelled' in PurchReqTable oppure un evento di annullamento del Workflow. Tipo di evento inferred
	Riga della richiesta chiusa	Una singola riga della richiesta di acquisto è considerata completamente elaborata. Questo avviene generalmente dopo la conversione completa della riga in un ordine di acquisto.
Perché è importante Fornisce un livello di dettaglio granulare sull'evasione delle richieste e aiuta a identificare se le richieste sono state convertite parzialmente o completamente in ordini di acquisto. Dove reperirlo Viene dedotto dal campo di stato della singola tabella 'PurchReqLine'. Uno stato che indica che la riga è stata ordinata o ricevuta ne segnala la chiusura. Acquisizione Monitori il campo di stato nella tabella PurchReqLine alla ricerca di un valore terminale come 'Invoiced' o 'Closed'. Tipo di evento inferred

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da Microsoft Dynamics 365

Passaggi

Acceda all’area di lavoro Gestione dati: acceda a Microsoft Dynamics 365 e apra il menu Aree di lavoro. Selezioni Gestione dati per aprire l’hub centrale delle operazioni di importazione ed esportazione dei dati.
Crei un nuovo progetto di esportazione: nell’area di lavoro Gestione dati, faccia clic sul riquadro Esporta. Indichi un Nome del Group univoco, una Descrizione descrittiva e imposti la Categoria del progetto su Progetto. In questo modo organizzerà le attività di estrazione dei dati.
Aggiunga le entità dati: aggiunga al progetto le entità dati standard necessarie. Faccia clic su Aggiungi entità e cerchi ciascuna delle seguenti entità, aggiungendole una alla volta:
- Testate delle richieste di acquisto
- Righe delle richieste di acquisto
- Tabella degli stati di monitoraggio del flusso di lavoro
- Elementi di lavoro del flusso di lavoro
- Righe degli ordini di acquisto V2
Definisca il formato di esportazione: per ogni entità aggiunta, selezioni un Formato dati di destinazione, ad esempio CSV o Excel. In genere, CSV è consigliato per le prestazioni e la compatibilità con gli strumenti di trasformazione dei dati.
Applichi i filtri ai dati: selezioni un’entità, quindi faccia clic sul pulsante Filtro. Nella scheda Intervallo, specifichi l’Entità giuridica (codice società) per assicurarsi di estrarre i dati dall’unità aziendale corretta. È inoltre fondamentale aggiungere un filtro per data al campo Data e ora di creazione dell’entità Testate delle richieste di acquisto per limitare il volume dei dati. Si consiglia di iniziare con un periodo compreso tra 3 e 6 mesi.
Esegua il processo di esportazione: dopo aver configurato tutte le entità e i filtri, faccia clic su Esporta nel riquadro delle azioni. Il sistema creerà un pacchetto di processo e avvierà l’elaborazione. Potrà monitorare l’avanzamento nella sezione Cronologia processi.
Scarichi il pacchetto di dati: al termine del processo di esportazione, acceda ai dettagli della Cronologia processi e faccia clic su Scarica pacchetto. Verrà scaricato un file ZIP contenente i file di dati separati per ogni entità.
Trasformi i dati grezzi in un Event Log: i file esportati rappresentano tabelle grezze del sistema, non un Event Log finale. Deve utilizzare uno strumento esterno, come Python, Power Query o una piattaforma ETL, per combinare e riorganizzare i dati. Questa operazione comprende:
- Unire i file di testata e di posizione.
- Unire i dati del flusso di lavoro alle richieste utilizzando CorrelationId e RecId della testata della richiesta di acquisto.
- Trasformare le modifiche di stato e gli eventi del flusso di lavoro delle tabelle del flusso di lavoro in righe di attività distinte (Richiesta inviata, Passaggio di approvazione approvato e così via).
- Creare una nuova riga per ogni attività con ActivityName, EventTime e PurchaseRequisitionId corretti.
Calcoli e associ gli attributi: durante la trasformazione, associ le colonne di origine agli attributi richiesti, come Utente e Reparto. Calcoli gli attributi derivati, come RequisitionTotalAmount, sommando gli importi delle righe. Imposti un valore statico per SourceSystemId (ad esempio, 'D365_F&O') e utilizzi l’ora di esecuzione dello script per LastDataIngestionTimestamp.
Completi e formatti l’output: verifichi 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 dell’Event Log, inclusi PurchaseRequisitionId, ActivityName ed EventTime.

Configurazione

Autorizzazioni necessarie: gli utenti devono disporre di un ruolo di sicurezza con autorizzazioni per il workspace Data management e accesso alle entità dati specifiche esportate, ad esempio Data management administrator o un ruolo personalizzato equivalente.
Entità dati principali:
- Purchase requisition headers: fornisce l'identificativo principale del caso, il timestamp di creazione e lo stato complessivo.
- Purchase requisition lines: contiene i dettagli di ciascun articolo richiesto, inclusi gli importi e i collegamenti agli ordini di acquisto.
- Workflow tracking status table: è la fonte principale per gli eventi del Workflow, come invio, approvazione, rifiuto e revoca.
- Workflow work items: descrive le attività specifiche assegnate agli utenti durante il processo di approvazione.
- Purchase order lines V2: viene utilizzata per individuare il timestamp di creazione dell'ordine di acquisto collegato a una riga della richiesta.
Filtro dell'intervallo di date: è fondamentale applicare un filtro per intervallo di date al campo Created date and time dell'entità Purchase requisition headers. Per l'analisi iniziale è consigliato un intervallo di 3-6 mesi, così da bilanciare il volume dei dati e la visibilità sul processo.
Filtro per codice azienda: applichi sempre un filtro per Legal entity per evitare di estrarre dati da società non pertinenti o di test. In questo modo ridurrà significativamente le dimensioni dei dati e migliorerà le prestazioni del processo.
Trasformazione dei dati: questo metodo richiede una fase significativa di post-elaborazione al di fuori di Dynamics 365 per trasformare le esportazioni grezze delle entità in un Event Log strutturato. Si prepari a utilizzare uno strumento di scripting o ETL.

a Query di esempio sql

/*
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;

Passaggi

Registri un'applicazione Azure Active Directory: acceda al portale Azure e registri una nuova applicazione. L'applicazione verrà utilizzata per autenticarsi con l'API Dynamics 365. Annoti l'ID applicazione (client) e l'ID directory (tenant).
Generi un segreto client: nell'applicazione appena registrata in Azure, crei un nuovo segreto client nella sezione «Certificates & secrets». Copi il valore del segreto e lo conservi in modo sicuro, poiché non sarà più visualizzabile.
Conceda le autorizzazioni API: nella sezione «API permissions» dell'applicazione aggiunga un'autorizzazione per «Dynamics ERP». Selezioni «Delegated permissions» e conceda Financials.ReadWrite.All o un equivalente di sola lettura più restrittivo. Conceda il consenso dell'amministratore per le autorizzazioni.
Installi le librerie Python: verifichi che Python sia installato. Quindi installi le librerie necessarie utilizzando pip: pip install requests pandas.
Configuri 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 Dynamics 365, Tenant ID, Client ID, Client Secret, intervallo di date desiderato e ID della società.
Comprenda le entità OData: lo script interroga tre entità dati principali: PurchaseRequisitionHeaders per i dettagli principali della richiesta, PurchaseRequisitionLines per i dettagli delle righe, inclusa la conversione in ordini di acquisto, e WorkflowTrackingStatusTable per tutti gli eventi relativi al Workflow, come invii e approvazioni.
Esegua lo script: esegua lo script dalla riga di comando: python extract_d365_requisitions.py. Lo script eseguirà l'autenticazione, recupererà i dati per ogni attività e gestirà automaticamente la paginazione dell'API.
Trasformi i dati: lo script elabora i dati JSON grezzi restituiti dalle chiamate API. Ristruttura i dati scorrendo i record e creando una riga distinta per ciascuna delle 12 attività aziendali, mappando i campi di origine sulle colonne standard dell'Event Log, come PurchaseRequisitionId, ActivityName e EventTime.
Combini e standardizzi gli eventi: tutti gli eventi generati vengono raccolti in un unico elenco e quindi convertiti in un DataFrame pandas. Lo script aggiunge colonne statiche come SourceSystemId e LastDataIngestionTimestamp.
Esporti in CSV: il DataFrame finale viene esportato in un file CSV denominato d365_purchase_requisition_log.csv. Il file è formattato per il caricamento diretto in uno strumento di Process Mining. Verifichi che sia codificato in UTF-8.

Configurazione

Prerequisiti: accesso a una sottoscrizione Azure per registrare un'applicazione. Sono necessari un ID applicazione (client), un Client Secret e un Tenant ID di Azure Active Directory. L'utente che esegue lo script deve disporre di credenziali che consentano l'accesso agli endpoint API OData di Dynamics 365 Finance and Operations.
Configurazione dell'endpoint API: lo script richiede l'URL di base dell'ambiente Dynamics 365, generalmente nel formato https://[your-environment-name].operations.dynamics.com.
Intervallo di date: imposti nello script le variabili START_DATE e END_DATE per definire la finestra di estrazione. Per l'analisi iniziale è consigliato un periodo da 3 a 6 mesi, così da bilanciare il volume dei dati e le informazioni ottenute.
Filtro per società: lo script è configurato per filtrare una specifica entità legale utilizzando la variabile COMPANY_ID. Per estrarre i dati di tutte le società, 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 all'Event Log utilizzando $select nelle query OData, migliorando così le prestazioni. Gestisce inoltre la paginazione per elaborare grandi set di dati senza sovraccaricare l'API. Per caricamenti storici molto estesi, valuti l'esecuzione dello script in batch con intervalli di date più brevi.

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()

Passaggi

Verifichi che il connettore nativo Microsoft Dynamics 365 Finance sia disponibile in Power BI Desktop e che l’utente disponga dell’autorizzazione ad accedere alle entità dati richieste, alla cronologia del Workflow, ai dati delle richieste di acquisto e ai relativi dati degli ordini di acquisto.
In Power BI Desktop, selezioni Recupera dati, scelga il connettore Microsoft Dynamics 365 Finance e inserisca l’URL dell’istanza Dynamics 365 Finance. Esegua l’autenticazione con un account autorizzato a leggere le entità richieste. Sostituisca [Your Dynamics 365 Finance instance URL] con l’URL dell’istanza del Suo ambiente.
In Navigator, selezioni le entità di testata e riga delle richieste di acquisto, le entità della cronologia o del monitoraggio del Workflow, le entità degli utenti e dell’organizzazione e le entità degli ordini di acquisto richieste dalla Sua implementazione. I nomi delle entità e i campi disponibili variano in base all’ambiente. Utilizzi i metadati delle entità e sostituisca ogni segnaposto nella query con l’entità e il campo corrispondenti esposti dal Suo sistema.
Carichi le entità selezionate in Power Query. Filtri i dati in base all’entità giuridica o società, al tipo di documento e al periodo di estrazione richiesti. Utilizzi i parametri [Start date] e [End date] e conservi i record il cui timestamp dell’evento rientra nel periodo selezionato. Includa i record creati prima della data di inizio quando presentano eventi di Workflow o di chiusura nel periodo, così da mantenere complete le cronologie dei casi.
Standardizzi gli identificativi e i timestamp. Converta in testo l’identificativo della richiesta di acquisto, converta tutti i timestamp degli eventi in un fuso orario UTC o aziendale coerente e mantenga la precisione del timestamp di origine. Verifichi che l’identificativo della testata della richiesta sia disponibile in ogni riga evento. Quando i record del Workflow contengono solo un identificativo di correlazione del Workflow, li colleghi alla testata della richiesta utilizzando la relazione documentata configurata nel Suo ambiente.
Crei una query degli eventi per ogni attività richiesta. Le query degli eventi devono restituire esplicitamente righe per Requisition Created, Requisition Submitted for Approval, Requisition Amended, Approval Step Started, Approval Step Approved, Approval Step Rejected, Requisition Approved, Requisition Rejected, Requisition Withdrawn, Purchase Order Created, Requisition Line Closed e Requisition Closed. Non faccia affidamento su ProcessMind per dedurre un’attività dalle variazioni di stato o dall’ordine degli eventi.
Per Requisition Amended, applichi la logica documentata di richiamo e nuova sottomissione prevista dalla cronologia del Workflow. Un’azione di richiamo seguita da una sottomissione successiva deve generare un evento di modifica al timestamp del richiamo oppure al timestamp della modifica esposto dall’entità di origine. Non crei una riga di modifica basandosi esclusivamente su una variazione dello stato della richiesta, a meno che il sistema di origine non registri esplicitamente tale variazione come modifica.
Per gli eventi relativi a righe e ordini di acquisto, colleghi le righe delle richieste alle righe degli ordini di acquisto utilizzando la relazione di origine documentata. Se l’Event Log è basato sul caso PurchaseRequisitionId, aggreghi gli eventi a livello di riga oppure li mantenga come righe separate con lo stesso identificativo del caso. Conservi gli identificativi delle righe in colonne aggiuntive quando disponibili, anche se non sono Attributi obbligatori.
Aggiunga le colonne di output obbligatorie PurchaseRequisitionId, ActivityName, EventTime, SourceSystemId e LastDataIngestionTimestamp. Aggiunga le colonne consigliate User, Department, RequisitionStatus, RequisitionTotalAmount, UrgencyLevel e ApprovalStep. Valorizzi con null i dati non disponibili, senza creare valori fittizi, e utilizzi un valore di origine coerente, ad esempio Dynamics 365 Finance, per SourceSystemId.
Accodi tutte le query delle attività con UNION ALL, rimuova le righe prive di identificativi del caso o di timestamp degli eventi e ordini i dati per PurchaseRequisitionId ed EventTime. Mantenga gli eventi duplicati quando rappresentano attività di Workflow distinte o righe di richieste separate. Rimuova i duplicati solo quando i record di origine sono dimostrabilmente estrazioni duplicate.
Convalidi l’Event Log risultante utilizzando i controlli descritti di seguito. Verifichi che ogni attività obbligatoria sia rappresentata da righe esplicite, che i timestamp rientrino nel periodo selezionato e che le join non moltiplichino gli eventi in modo imprevisto.
Carichi o esporti la tabella finale in formato CSV o in un altro formato di Event Log supportato da ProcessMind. Mappi PurchaseRequisitionId come identificativo del caso, ActivityName come attività ed EventTime come timestamp dell’evento. Mantenga SourceSystemId e LastDataIngestionTimestamp come Attributi dell’evento e conservi tutti gli Attributi consigliati quando disponibili.

Configurazione

Connettore e origine: utilizzi il connettore nativo Microsoft Dynamics 365 Finance in Power BI Desktop. Sostituisca [Your Dynamics 365 Finance instance URL] con l’URL dell’ambiente. I nomi delle entità e i campi devono essere verificati nei metadati di Navigator per l’implementazione specifica.
Entità obbligatorie: selezioni le entità di testata e riga delle richieste di acquisto, le entità di monitoraggio o cronologia del Workflow, le entità di testata e riga degli ordini di acquisto e le entità degli utenti o dell’organizzazione necessarie per l’arricchimento. Utilizzi i segnaposto [Your entity name] finché le entità esatte non saranno confermate.
Intervallo di date: inizi con un periodo compreso tra tre e sei mesi di dati. Includa le testate storiche delle richieste relative ai casi che presentano eventi di Workflow, ordini di acquisto, chiusura di riga o chiusura della richiesta durante il periodo selezionato.
Filtri per società e documento: applichi, ove pertinente, i filtri [Your company or legal entity filter] e [Your document type filter]. Verifichi se l’identificativo della richiesta è univoco a livello globale oppure solo all’interno di una società.
Ambito del Workflow: includa le azioni di sottomissione, richiamo, nuova sottomissione, assegnazione delle attività, approvazione, rifiuto, ritiro, completamento e annullamento. Configuri le mappature delle azioni e degli stati del Workflow in base ai valori utilizzati nell’ambiente.
Semantica degli eventi: ogni attività deve essere emessa come riga evento esplicita. ProcessMind non deduce eventi di approvazione, modifica, chiusura o conversione da altre righe.
Gestione dei timestamp: standardizzi tutti i timestamp su un unico fuso orario. Documenti se i timestamp di origine sono memorizzati in UTC o nell’ora locale aziendale. Utilizzi il timestamp di origine con la massima precisione disponibile.
Aggiornamento incrementale: per le estrazioni ricorrenti, utilizzi un watermark basato sul timestamp massimo di modifica o dell’evento di origine, con una finestra di sovrapposizione per acquisire i record di Workflow arrivati in ritardo. Riconcili la sovrapposizione prima di caricare l’Event Log finale.
Prestazioni: filtri le entità di origine prima delle join, selezioni solo le colonne necessarie, eviti di caricare dati storici del Workflow non necessari e utilizzi il query folding quando supportato. Estragga separatamente testate, righe, eventi del Workflow e relazioni degli ordini di acquisto prima di combinarli.
Autorizzazioni e prerequisiti: l’account deve disporre dell’accesso in lettura alle entità dati Microsoft Dynamics 365 Finance selezionate e ai dati del Workflow. Verifichi che le funzionalità pertinenti di approvvigionamento e Workflow siano abilitate e che Power BI Desktop, il connettore, la configurazione del gateway, se applicabile, e le policy di sicurezza dell’organizzazione consentano l’estrazione.
Valuta e importi: verifichi la valuta rappresentata da RequisitionTotalAmount. Se le richieste possono contenere più valute, includa la valuta di origine come Attributo aggiuntivo e non converta gli importi senza indicarlo.
Gestione dei valori null: gli Attributi consigliati possono essere null quando il sistema di origine non memorizza un valore, quando il valore è limitato dalle autorizzazioni di sicurezza o quando non è possibile risolvere la relazione. I valori obbligatori relativi a caso, attività e timestamp dell’evento devono essere convalidati prima dell’esportazione.

a Query di esempio sql

WITH
RequisitionHeader AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [CreatedDateTimeField] AS CreatedDateTime,
        [RequisitionStatusField] AS RequisitionStatus,
        [RequisitionTotalAmountField] AS RequisitionTotalAmount,
        [UrgencyLevelField] AS UrgencyLevel,
        [RequesterUserField] AS RequesterUser,
        [DepartmentField] AS Department
    FROM [Your requisition header entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [DocumentTypeField] = '[Your document type filter]'
),
WorkflowEvents AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [WorkflowEventTimestampField] AS EventTime,
        [WorkflowActionField] AS WorkflowAction,
        [WorkflowStatusField] AS WorkflowStatus,
        [ApprovalStepField] AS ApprovalStep,
        [WorkflowUserField] AS EventUser,
        [WorkflowCorrelationField] AS WorkflowCorrelation
    FROM [Your workflow history or workflow tracking entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [WorkflowEventTimestampField] >= CAST('[Start date]' AS datetime2)
      AND [WorkflowEventTimestampField] < CAST('[End date]' AS datetime2)
),
PurchaseOrderLinks AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [PurchaseRequisitionLineIdField] AS PurchaseRequisitionLineId,
        [PurchaseOrderIdField] AS PurchaseOrderId,
        [PurchaseOrderLineIdField] AS PurchaseOrderLineId,
        [PurchaseOrderCreatedDateTimeField] AS PurchaseOrderCreatedDateTime,
        [RequisitionLineClosedDateTimeField] AS RequisitionLineClosedDateTime
    FROM [Your requisition to purchase order relationship entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
RequisitionClosure AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [RequisitionClosedDateTimeField] AS RequisitionClosedDateTime
    FROM [Your requisition closure entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
Events AS (
    SELECT
        h.PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        h.CreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionHeader h
    WHERE h.CreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Submitted for Approval' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your submission action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your recall action value]')
      AND EXISTS (
          SELECT 1
          FROM WorkflowEvents w2
          WHERE w2.PurchaseRequisitionId = w.PurchaseRequisitionId
            AND w2.WorkflowAction IN ('[Your resubmission action value]')
            AND w2.EventTime > w.EventTime
      )

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval task assigned action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval action value]')
      AND w.WorkflowStatus IN ('[Your approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]')
      AND w.WorkflowStatus IN ('[Your final approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]', '[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your final rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your withdrawal or cancellation action value]')

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        p.PurchaseOrderCreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.PurchaseOrderCreatedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.PurchaseOrderCreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Requisition Line Closed' AS ActivityName,
        p.RequisitionLineClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.RequisitionLineClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.RequisitionLineClosedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        c.PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        c.RequisitionClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionClosure c
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = c.PurchaseRequisitionId
    WHERE c.RequisitionClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND c.RequisitionClosedDateTime < CAST('[End date]' AS datetime2)
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    SourceSystemId,
    LastDataIngestionTimestamp,
    [User],
    Department,
    RequisitionStatus,
    RequisitionTotalAmount,
    UrgencyLevel,
    ApprovalStep
FROM Events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Pronto per iniziare?

Con questo Template ha tutto ciò che Le serve per iniziare a ottimizzare il processo Purchase to Pay - Richiesta. Inizi oggi stesso a scoprire informazioni di valore.

Torna alla guida al miglioramento Scarica il Template

Ottimizzi subito Purchase to Pay - Richiesta per ottenere approvazioni più rapide

Elimini i ritardi e ottenga tempi di ciclo più brevi del 30% in Dynamics 365.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Configurazione in pochi minuti.

Il Suo Template dei dati Purchase to Pay - Richiesta

Il Suo Template dei dati Purchase to Pay - Richiesta

Purchase to Pay - Requisition: attributi

Purchase to Pay - Requisition: attività

Guide all'estrazione

Esportazione tramite Data Management Framework di Dynamics 365

Passaggi

Configurazione

a Query di esempio sql

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

Passaggi

Configurazione

a Query di esempio python

Estrazione tramite il connettore nativo Microsoft Power BI

Passaggi

Configurazione

a Query di esempio sql

Pronto per iniziare?

Ottimizzi subito Purchase to Pay - Richiesta per ottenere approvazioni più rapide

Il Suo Template dei dati Purchase to Pay - Richiesta

Il Suo Template dei dati Purchase to Pay - Richiesta

Purchase to Pay - Requisition: attributi

Purchase to Pay - Requisition: attività

Guide all'estrazione

Esportazione tramite Data Management Framework di Dynamics 365

Passaggi

Configurazione

a Query di esempio sql

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

Passaggi

Configurazione

a Query di esempio python

Estrazione tramite il connettore nativo Microsoft Power BI

Passaggi

Configurazione

a Query di esempio sql

Pronto per iniziare?

Ottimizzi subito Purchase to Pay - Richiesta per ottenere approvazioni più rapide

La Sua privacy è importante