> Miglioramento continuo dei processi > Acquisto e pagamento, richieste > Microsoft Dynamics 365 > Template dei dati

Il Suo template di dati per Purchase-to-Pay - Richieste di acquisto

Microsoft Dynamics 365

Attributi di Purchase-to-Pay - Richieste di acquisto(17) Attività di Purchase-to-Pay - Richieste di acquisto(12) Guide all’estrazione(3)

Il Suo template di dati per Purchase-to-Pay - Richieste di acquisto

Questo template indica gli attributi principali da raccogliere e le attività essenziali da tracciare, per analizzare nel dettaglio il processo di richiesta di acquisto. Fornisce inoltre indicazioni pratiche su come estrarre questi dati e preparare in modo efficiente l’event log per un’analisi approfondita.

Attributi consigliati da raccogliere
Attività principali da tracciare
Indicazioni per l’estrazione

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

Scarica il template

Attributi di Purchase-to-Pay - Richieste di acquisto

Questi sono i campi dati consigliati da includere nell’event log per analizzare in modo completo il processo Purchase-to-Pay - Richieste di acquisto.

5 Obbligatorio 6 Consigliato 6 Facoltativo

	Nome	Descrizione
	Data e ora dell’evento EventTime	Data e ora esatte in cui si è verificata una specifica attività o un evento.
Descrizione La data e l’ora dell’evento, ovvero la marca temporale, indicano quando un evento aziendale è stato registrato nel sistema. Costituiscono la base temporale per tutte le analisi dei processi basate sul tempo. Questo attributo è fondamentale per calcolare i tempi di ciclo, le durate e i tempi di attesa tra le attività. Consente di analizzare le prestazioni del processo, individuare i colli di bottiglia e monitorare il rispetto degli SLA. Per un’analisi di Process Mining affidabile sono indispensabili marche temporali precise. Perché è importante Fornisce l’ordine cronologico degli eventi, necessario per calcolare la durata dei processi, individuare i colli di bottiglia e analizzare l’andamento nel tempo. Dove reperirli Si trova nelle tabelle dello storico del flusso di lavoro o nei log dei documenti, spesso in un 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
	ID della richiesta d’acquisto PurchaseRequisitionId	Identificativo univoco della richiesta d’acquisto, utilizzato come identificativo principale del caso.
Descrizione L’ID della richiesta d’acquisto è la chiave centrale che collega tutte le attività relative a una singola richiesta di beni o servizi. Ogni richiesta, dalla creazione all’approvazione finale e alla chiusura, viene tracciata tramite questo ID univoco. Nel Process Mining, questo attributo è fondamentale per ricostruire il percorso completo 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 delle richieste. Perché è importante È essenziale per raggruppare tutti gli eventi correlati in una singola istanza di processo e consentire un’analisi completa, dall’inizio alla fine, del ciclo di vita di ogni richiesta. Dove reperirli In genere, è la chiave primaria della tabella principale che contiene l’intestazione della richiesta d’acquisto, come PurchReqTable in Microsoft Dynamics 365. Esempi PR-001254PR-001255PR-001256
	Nome dell’attività ActivityName	Nome dello specifico evento aziendale o passaggio che si è verificato nel processo della richiesta d’acquisto.
Descrizione Questo attributo registra il nome di ogni attività svolta durante il ciclo di vita della richiesta d’acquisto. Alcuni esempi sono 'Richiesta d’acquisto creata', 'Fase di approvazione approvata' e 'Ordine d’acquisto creato'. Queste attività costituiscono i nodi della mappa di processo individuata. L’analisi della sequenza, della frequenza e della durata tra le attività è alla base del Process Mining. Aiuta a individuare colli di bottiglia, cicli di rilavorazione e deviazioni dal flusso di processo standard, facendo emergere le inefficienze operative. Perché è importante Questo attributo definisce le fasi della mappa di processo e consente di visualizzare, analizzare e comprendere il flusso di lavoro delle richieste d’acquisto. Dove reperirli In genere, si ricava dai log delle variazioni di stato, dalle tabelle dello storico del flusso di lavoro o da tabelle di eventi specifiche di Microsoft Dynamics 365, come WorkflowTrackingStatusTable. Esempi Richiesta d’acquisto inviata per l’approvazioneFase di approvazione approvataRichiesta d’acquisto modificata
	Sistema di origine SourceSystemId	Sistema di registrazione da cui sono stati estratti i dati.
Descrizione Questo attributo identifica il sistema di origine da cui provengono i dati degli eventi. In questo caso, sarebbe 'Microsoft Dynamics 365'. Negli ambienti con più sistemi integrati, il campo è fondamentale per ricostruire la provenienza dei dati e il relativo contesto. Nell’analisi, aiuta a distinguere i processi che coinvolgono più sistemi o a confermare che i dati provengono da un’unica fonte autorevole. È importante per convalidare i dati e assicurarsi che l’analisi si basi sull’insieme di dati corretto. Perché è importante Fornisce informazioni sull’origine dei dati, fondamentali per la governance e la convalida dei dati, nonché negli ambienti in cui sono integrati più sistemi. Dove reperirli È 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	Data e ora dell’ultima estrazione dei dati e del loro caricamento nello strumento di Process Mining.
Descrizione Questo attributo indica quanto sono aggiornati i dati analizzati. Riporta la data e l’ora dell’ultimo aggiornamento dei dati dal sistema di origine. Non è un campo di Dynamics 365, ma un metadato aggiunto durante l’acquisizione dei dati. Questa marca temporale è fondamentale per capire quanto siano aggiornate le informazioni. Aiuta a stabilire se si stanno consultando dati in tempo reale o un’istantanea riferita a un momento specifico, aspetto che incide sulla pertinenza delle conclusioni. Perché è importante Informa gli utenti sull’aggiornamento dei dati, aiutandoli a comprendere il periodo a cui si riferisce l’analisi e la pertinenza delle informazioni emerse. Dove reperirli Questo valore viene generato e aggiunto all’insieme di dati durante l’acquisizione o il processo ETL. Esempi 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Importo totale della richiesta RequisitionTotalAmount	Valore monetario complessivo della richiesta di acquisto.
Descrizione Questo attributo registra il valore totale di tutte le righe di una richiesta di acquisto. L’importo spesso influisce sulla complessità del flusso di lavoro di approvazione: le richieste di importo più elevato richiedono in genere più passaggi di approvazione. Nell’analisi dei processi, questo attributo è essenziale per filtrare e analizzare i dati in base al valore. Aiuta a rispondere a domande come «Le richieste di importo elevato richiedono più tempo per essere approvate?» oppure «Qual è il valore delle richieste attualmente bloccate nel processo?». In questo modo, l’analisi delle prestazioni del processo acquista un contesto finanziario. Perché è importante Aggiunge una dimensione finanziaria all’analisi, consentendo di dare priorità ai casi di importo elevato e di capire in che modo il valore monetario influisce sul comportamento del processo. Dove reperirli Questo valore si trova in genere nella tabella dell’intestazione della richiesta di acquisto oppure si calcola sommando gli importi delle righe nella tabella delle righe della richiesta di acquisto (PurchReqLine). Esempi 1500.0025000.50500.75
	Livello di urgenza UrgencyLevel	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 usato per determinare il percorso di approvazione o per stabilire le priorità di lavoro di chi approva. Analizzare questo attributo aiuta a capire se il sistema di priorità è efficace. Per esempio, è possibile confrontare i tempi di ciclo delle richieste con urgenza «Alta» e «Bassa». Se la differenza è trascurabile, il campo della priorità potrebbe essere ignorato o usato in modo improprio. È un’indicazione importante per la Dashboard «Analisi dell’impatto del livello di urgenza». Perché è importante Aiuta a valutare se le impostazioni di priorità accelerano davvero le richieste critiche e a individuare eventuali usi impropri della classificazione dell’urgenza. Dove reperirli Potrebbe essere un campo standard o personalizzato della tabella PurchReqTable. La sua presenza e il suo nome possono variare in base alla configurazione del sistema. Esempi AltaMediaBassa
	Passaggio di approvazione ApprovalStep	Nome o fase di uno specifico passaggio di approvazione nel flusso di lavoro.
Descrizione Questo attributo identifica una fase specifica del flusso di lavoro di approvazione, ad esempio «Approvazione del responsabile» o «Approvazione della finanza». Fornisce un livello di dettaglio maggiore rispetto al nome generico dell’attività. Questo attributo è essenziale per l’«Analisi dei colli di bottiglia nei passaggi di approvazione». Tracciando il tempo trascorso in ciascun passaggio di approvazione, è possibile individuare con precisione le fasi che causano ritardi nel processo complessivo. Ciò consente di intervenire in modo mirato per migliorare l’efficienza del flusso di lavoro. Perché è importante Consente di analizzare nel dettaglio il flusso di lavoro di approvazione e di individuare le fasi specifiche che causano colli di bottiglia. Dove reperirli Queste informazioni sono contenute nelle tabelle della cronologia del flusso di lavoro, come WorkflowTrackingStatusTable, che riporta ogni passaggio del flusso di lavoro configurato. Esempi Approvazione del responsabileApprovazione del responsabile di repartoRevisione della finanza
	Reparto Department	Reparto del richiedente o centro di costo associato alla richiesta d’acquisto.
Descrizione Questo attributo specifica il reparto aziendale o il centro di costo che ha avviato la richiesta d’acquisto, ad esempio 'Marketing', 'IT' o 'Operations'. Di solito, queste informazioni fanno parte dell’intestazione della richiesta. Segmentare il processo per reparto è fondamentale per l’analisi comparativa. Consente di individuare i reparti con i tempi di ciclo più lunghi, i tassi di rifiuto più elevati o il maggior numero di modifiche. Queste informazioni aiutano a definire interventi di miglioramento adatti alle esigenze specifiche di ciascun reparto. Perché è importante Consente di filtrare e confrontare l’andamento del processo tra diverse unità aziendali, facendo emergere schemi, colli di bottiglia o inefficienze specifici dei singoli reparti. Dove reperirli 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 corrente o finale della richiesta di acquisto.
Descrizione Questo attributo indica lo stato complessivo della richiesta di acquisto in un determinato momento, ad esempio «In revisione», «Approvato», «Rifiutato» o «Chiuso». Spesso è un attributo a livello di caso che rappresenta l’esito finale. Analizzare lo stato finale aiuta a comprendere gli esiti complessivi del processo. Per esempio, un numero elevato di richieste «Rifiutate» o «Ritirate» può indicare problemi nella fase iniziale della richiesta o un processo di approvazione macchinoso. Questo dato è fondamentale per misurare il tasso di successo e l’efficienza del processo. Perché è importante Fornisce un esito chiaro per ogni caso e consente di analizzare i tassi di approvazione, rifiuto e ritiro, che sono indicatori chiave delle prestazioni. Dove reperirli Il campo dello stato si trova in genere nella tabella dell’intestazione della richiesta di acquisto, PurchReqTable, e si chiama spesso «Status» o «PurchReqStatus». Esempi ApprovatoIn revisioneRifiutatoBozza
	Utente User	ID o nome dell’utente che ha svolto l’attività.
Descrizione Questo attributo identifica il dipendente o l’utente di sistema responsabile di una specifica fase del processo, come l’invio di una richiesta d’acquisto o l’approvazione di una richiesta. Può contenere un ID utente, il nome completo o l’indirizzo e-mail. Analizzare le attività per utente aiuta a individuare esigenze formative, persone o team con prestazioni elevate e modalità di distribuzione dei carichi di lavoro. È inoltre essenziale per l’analisi della conformità, ad esempio per verificare la separazione dei compiti e comprendere come i diversi ruoli interagiscono con il processo. Perché è importante Consente di analizzare il comportamento, il carico di lavoro e le prestazioni dei singoli utenti, aspetti fondamentali per la gestione delle risorse e l’individuazione di opportunità formative. Dove reperirli In genere, si trova nelle tabelle dello storico del flusso di lavoro, 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	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 verso l’approvazione non include attività «Richiesta modificata» o «Passaggio di approvazione rifiutato»; 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 delle rilavorazioni a livello di caso. Un tasso basso 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 individuando i casi che hanno richiesto rilavorazioni e supportando i KPI basati sul tasso di completamento corretto al primo tentativo. Dove reperirli È un attributo calcolato. Durante la trasformazione dei dati, occorre analizzare l’intera sequenza di attività di ciascun caso per verificare che prima dell’approvazione non siano presenti attività di rilavorazione. Esempi truefalse
	Gruppo di approvazione ApproverGroup	Gruppo di utenti o ruolo responsabile di un passaggio di approvazione.
Descrizione Questo attributo identifica il gruppo, il ruolo o la coda a cui è assegnato un determinato task di approvazione, ad esempio «Addetti alle approvazioni finanziarie» o «Responsabili IT». Analizzare le prestazioni del processo per gruppo di approvazione è fondamentale per comprendere la distribuzione del carico di lavoro e individuare i gruppi che potrebbero avere risorse insufficienti o aver bisogno di ulteriore formazione. La Dashboard «Analisi dei colli di bottiglia nei passaggi di approvazione» consente di suddividere i dati sulle prestazioni in base ai team responsabili delle approvazioni. Perché è importante Aiuta a individuare le differenze di prestazioni tra i team di approvazione e a rilevare eventuali carenze di risorse o necessità di formazione nei singoli gruppi. Dove reperirli Queste informazioni fanno parte della cronologia del flusso di lavoro, ad esempio WorkflowTrackingStatusTable, che registra l’utente o il gruppo di utenti assegnato a ciascun task. Esempi Addetti alle approvazioni finanziarieResponsabili ITDirigenza senior
	Numero dell’ordine di acquisto PurchaseOrderNumber	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. Collega il processo di richiesta a quello di approvvigionamento che segue. Tracciare questo numero è essenziale per analizzare il «Tempo di conversione da richiesta a ordine di acquisto». Conferma che la richiesta è passata correttamente alla fase successiva del ciclo Purchase-to-Pay e consente di analizzare l’intero processo, dalla richiesta all’ordine di acquisto. Perché è importante Collega la richiesta al successivo ordine di acquisto, consentendo di analizzare la conversione da richiesta a ordine e di collegare le diverse fasi del processo P2P. Dove reperirli Dopo la creazione dell’ordine di acquisto, queste informazioni si trovano di solito nella tabella delle righe della richiesta di acquisto (PurchReqLine), collegata a PurchTable. Esempi PO-000987PO-000988PO-000989
	Numero di modifiche AmendmentCount	Numero complessivo di modifiche apportate alla richiesta.
Descrizione Si tratta di un attributo numerico calcolato, che conta quante volte si verifica l’attività «Richiesta modificata» per ciascun caso di richiesta di acquisto. Questo attributo è essenziale per la Dashboard «Frequenza di modifica delle richieste» e per il KPI «Tasso di modifica delle richieste». Quantifica le rilavorazioni per caso e facilita l’individuazione delle richieste, dei reparti o degli utenti associati a un numero elevato di modifiche e a inefficienze. Aiuta così a concentrare gli interventi sul miglioramento della qualità delle richieste iniziali. Perché è importante Quantifica le rilavorazioni all’interno di un caso e facilita la misurazione e l’analisi della frequenza delle modifiche e del loro impatto sull’efficienza del processo. Dove reperirli È un attributo calcolato, ricavato durante la trasformazione dei dati contando le attività «Richiesta modificata» per ogni PurchaseRequisitionId univoco. Esempi 013
	Percorso del flusso di lavoro di approvazione ApprovalWorkflowPath	Rappresentazione della sequenza dei passaggi di approvazione eseguiti.
Descrizione Questo attributo è un campo derivato che concatena la sequenza dei passaggi di approvazione di una richiesta, ad esempio «Approvazione del responsabile -> Approvazione del responsabile di reparto -> Approvazione della finanza». Riassume in modo efficace la variante del sottoprocesso di approvazione. È fondamentale per la Dashboard «Monitoraggio degli scostamenti di conformità». Confrontando il percorso effettivo del flusso di lavoro con un percorso standard o previsto, è facile segnalare flussi non conformi o insoliti, che potrebbero indicare violazioni delle policy o rischi operativi. Perché è importante Semplifica l’analisi della conformità rappresentando chiaramente la variante del processo e facilitando l’individuazione degli scostamenti dalle procedure standard. Dove reperirli Questo attributo non è un campo standard. Durante la trasformazione dei dati, occorre ricavarlo concatenando in ordine cronologico i valori di «ApprovalStep» per ciascun caso. Esempi Responsabile -> DirettoreResponsabile -> Direttore -> Vicepresidente della finanzaResponsabile -> Approvazione automatica
	Valuta Currency	Il codice della valuta in cui è espresso l’importo della richiesta.
Descrizione Questo attributo specifica la valuta, ad esempio USD, EUR o GBP, in cui è espresso l’importo totale della richiesta. È fondamentale per l’analisi finanziaria, soprattutto nelle organizzazioni multinazionali che gestiscono più valute. L’attributo della valuta consente di gestire e aggregare correttamente i dati finanziari. Garantisce che i valori monetari siano interpretati nel modo corretto e permette di convertirli in una valuta comune, così da ottenere report e confronti accurati tra regioni o unità aziendali diverse. Perché è importante Fornisce il contesto necessario per interpretare gli attributi finanziari e aggregare correttamente i valori monetari in ambienti con più valute. Dove reperirli Questo campo si trova in genere nella tabella dell’intestazione della richiesta di acquisto, PurchReqTable, insieme ai campi relativi agli importi. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Attività di Purchase-to-Pay - Richieste di acquisto

Questi sono i passaggi e le tappe fondamentali da registrare nell’event log per individuare e analizzare con precisione il flusso di lavoro delle richieste di acquisto.

7 Consigliato 5 Facoltativo

	Attività	Descrizione
	Fase di approvazione approvata	L’approvatore completa l’attività assegnata e approva la richiesta per la fase di processo di sua competenza. La richiesta passa così alla fase successiva o all’approvazione finale.
Perché è importante Misura il tempo di elaborazione di ogni fase di approvazione e aiuta a individuare i passaggi più efficienti del flusso di lavoro. È un elemento fondamentale dell’analisi delle varianti. Dove reperirli L’evento viene registrato esplicitamente nella 'WorkflowTrackingStatusTable' quando un utente completa un elemento di lavoro con esito 'Approve'. Acquisizione Individuare nei log dello storico del flusso di lavoro gli eventi 'WorkItemCompleted' con esito 'Approve'. Tipo di evento explicit
	Ordine d’acquisto creato	Una riga approvata della richiesta d’acquisto viene convertita in una riga dell’ordine d’acquisto, segnando il passaggio al team acquisti. L’evento si rileva collegando la riga della richiesta a quella dell’ordine.
Perché è importante È una tappa fondamentale che collega la richiesta al successivo processo di acquisto. È essenziale per misurare il KPI 'Tempo di conversione da richiesta a ordine d’acquisto'. Dove reperirli L’evento si deduce individuando nella tabella 'PurchLine' un record che fa riferimento all’ID di una 'PurchReqLine' associata al caso della richiesta. Acquisizione Unire PurchReqLine e PurchLine tramite il campo di riferimento che le collega, ad esempio PurchReqLineRefId. Tipo di evento inferred
	Richiesta d’acquisto approvata	La richiesta ha superato tutte le fasi di approvazione previste nel flusso di lavoro. L’attività viene rilevata quando l’istanza del flusso di lavoro si conclude con lo stato finale di approvazione.
Perché è importante È una tappa fondamentale, che segna la fine del ciclo di approvazione e l’inizio della fase di acquisto. È l’evento finale del KPI 'Tempo del ciclo di approvazione della richiesta'. Dove reperirli L’evento si ricava esplicitamente dalla 'WorkflowTrackingStatusTable' al completamento del flusso di lavoro. Inoltre, il campo 'Status' della 'PurchReqTable' viene aggiornato a 'Approved'. Acquisizione Filtrare gli eventi 'Completion' del flusso di lavoro con stato 'Approved' oppure monitorare le variazioni di stato nella PurchReqTable. Tipo di evento explicit
	Richiesta d’acquisto chiusa	La richiesta d’acquisto nel suo complesso è considerata completata quando tutte le righe sono state convertite in ordini d’acquisto o annullate. Si tratta di uno stato finale positivo.
Perché è importante Questa attività segna il completamento del ciclo di vita della richiesta. È il punto finale per misurare la durata complessiva del processo dall’inizio alla fine. Dove reperirli In genere, questo stato viene calcolato o dedotto. Si verifica quando tutti i record 'PurchReqLine' associati raggiungono uno stato finale, ad esempio 'Closed' o 'Cancelled'. Acquisizione Derivare questo evento verificando che tutti i record PurchReqLine associati a una PurchReqTable abbiano raggiunto uno stato finale. Tipo di evento calculated
	Richiesta d’acquisto creata	Questo evento segna la creazione iniziale del record della richiesta d’acquisto, che si trova nello stato di bozza. Viene rilevato tramite la data e l’ora di creazione dell’intestazione della richiesta.
Perché è importante In quanto punto di avvio del processo, questa attività è essenziale per misurare la durata complessiva del ciclo di vita delle richieste e analizzare i volumi giornalieri di richieste gestite. Dove reperirli Questa attività si deduce dal campo 'createdDateTime' della tabella 'PurchReqTable' per ogni nuovo ID della richiesta d’acquisto. Acquisizione Utilizzare la data e l’ora di creazione del record nella tabella PurchReqTable. Tipo di evento inferred
	Richiesta d’acquisto inviata per l’approvazione	L’utente invia la richiesta d’acquisto compilata, avviando il flusso di lavoro formale di approvazione. Il motore del flusso di lavoro registra esplicitamente questa azione.
Perché è importante Questa attività è una tappa fondamentale che dà inizio al ciclo di approvazione. È il punto di partenza per misurare il 'Tempo del ciclo di approvazione della richiesta' e il 'Tasso di approvazione al primo passaggio'. Dove reperirli Il dato si ricava dalla 'WorkflowTrackingStatusTable' o da una tabella analoga dello storico del flusso di lavoro, in cui viene registrato un evento 'Submission' associato alla richiesta d’acquisto. Acquisizione Filtrare i log dello storico del flusso di lavoro per individuare gli eventi di tipo 'Submission' o 'Start' associati alla richiesta. Tipo di evento explicit
	Richiesta d’acquisto rifiutata	La richiesta è stata rifiutata durante il flusso di lavoro di approvazione e non verrà elaborata ulteriormente. Si tratta di uno stato finale di esito negativo per la richiesta.
Perché è importante Questo evento finale è fondamentale per analizzare il tasso complessivo di rifiuto e comprendere l’impatto finanziario o operativo delle richieste non approvate. Dove reperirli L’evento si ricava esplicitamente dalla 'WorkflowTrackingStatusTable' al completamento del flusso di lavoro con stato 'Rejected'; viene così aggiornato il campo di stato della 'PurchReqTable'. Acquisizione Filtrare gli eventi 'Completion' del flusso di lavoro con stato 'Rejected' oppure monitorare le variazioni di stato nella PurchReqTable. Tipo di evento explicit
	Fase di approvazione avviata	Una singola attività di approvazione viene assegnata a un utente o a un gruppo nell’ambito del flusso di lavoro. Da questo momento inizia il tempo di attesa o di elaborazione per uno specifico approvatore.
Perché è importante Questa attività è essenziale per l’'Analisi dei colli di bottiglia nelle fasi di approvazione', perché consente di misurare i tempi di attesa nelle code per ogni fase. Dove reperirli Il dato si ricava dalla 'WorkflowTrackingStatusTable' quando viene creato e assegnato un nuovo elemento di lavoro nell’istanza del flusso di lavoro della richiesta. Acquisizione Individuare gli eventi 'WorkItemCreated' o eventi analoghi nei log dello storico del flusso di lavoro relativi alla richiesta. Tipo di evento explicit
	Fase di approvazione rifiutata	L’approvatore rifiuta l’attività assegnata, rinviando in genere la richiesta al mittente perché la corregga. Il motore del flusso di lavoro registra esplicitamente questa azione.
Perché è importante Questa attività è fondamentale per calcolare il 'Tasso di rifiuto delle richieste' e individuare le fasi in cui i rifiuti si verificano più spesso, mettendo in luce le aree da migliorare. Dove reperirli L’evento viene registrato esplicitamente nella 'WorkflowTrackingStatusTable' quando un utente completa un elemento di lavoro con esito 'Reject'. Acquisizione Individuare nei log dello storico del flusso di lavoro gli eventi 'WorkItemCompleted' con esito 'Reject'. Tipo di evento explicit
	Richiesta d’acquisto modificata	Questo evento si verifica quando un utente ritira dal flusso di lavoro una richiesta già inviata per apportarvi modifiche. In genere, l’attività si rileva individuando un’azione di ritiro seguita da un nuovo invio.
Perché è importante Monitorare le modifiche è fondamentale per individuare le rilavorazioni, le richieste iniziali poco chiare e le inefficienze del processo. Questo dato alimenta direttamente la Dashboard 'Frequenza di modifica delle richieste'. Dove reperirli L’evento si può dedurre dallo storico del flusso di lavoro ('WorkflowTrackingStatusTable'), rilevando un’azione 'Recall' o 'RequestChange'. Può anche essere dedotto dalle modifiche al campo 'modifiedDateTime' della tabella 'PurchReqTable' successive all’invio. Acquisizione Rilevare gli eventi di ritiro dal flusso di lavoro o le modifiche alle versioni dei record tra un invio e l’altro. Tipo di evento inferred
	Richiesta d’acquisto ritirata	Il creatore o un utente autorizzato annulla la richiesta dopo l’invio. L’azione termina il flusso di lavoro e la richiesta.
Perché è importante Monitorare i ritiri aiuta a individuare problemi nella pianificazione della domanda o processi eccessivamente complessi. Questi dati alimentano la Dashboard 'Informazioni sui ritiri delle richieste'. Dove reperirli L’evento si deduce dalla modifica dello stato della 'PurchReqTable' in 'Cancelled' oppure da un evento 'Cancel' nella 'WorkflowTrackingStatusTable'. Acquisizione Rilevare la modifica dello stato in 'Cancelled' nella PurchReqTable oppure un evento di annullamento del flusso di lavoro. Tipo di evento inferred
	Riga della richiesta d’acquisto chiusa	Una singola riga della richiesta d’acquisto è considerata completamente elaborata. In genere, ciò avviene quando la riga è stata convertita interamente in un ordine d’acquisto.
Perché è importante Fornisce informazioni dettagliate sull’evasione delle richieste e aiuta a capire se vengono convertite in ordini d’acquisto solo in parte o per intero. Dove reperirli L’evento si deduce dal campo di stato della singola tabella 'PurchReqLine'. Uno stato che indica che la riga è stata ordinata o ricevuta ne segnala la chiusura. Acquisizione Monitorare il campo di stato della tabella PurchReqLine per rilevare un valore finale come 'Invoiced' o 'Closed'. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Microsoft Dynamics 365

Passaggi

Acceda all’area di lavoro Data Management: Acceda a Microsoft Dynamics 365 e apra il menu Workspaces. Selezioni Data management per aprire l’area centrale dedicata alle operazioni di importazione ed esportazione dei dati.
Crei un nuovo progetto di esportazione: Nell’area di lavoro Data Management, selezioni il riquadro Export. Inserisca un Nome del Group univoco e una Descrizione chiara, quindi imposti Project category su Project. In questo modo organizzerà le attività di estrazione dei dati.
Aggiunga le entità dati: Aggiunga al progetto le entità dati standard necessarie. Selezioni Add entity, cerchi ciascuna delle entità seguenti e le aggiunga una alla volta:
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Definisca il formato di esportazione: Per ogni entità aggiunta, selezioni un Target data format, 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 la Legal entity (codice società) per assicurarsi di estrarre i dati dall’unità aziendale corretta. È inoltre fondamentale applicare un filtro per data al campo Created date and time dell’entità Purchase requisition headers, così da limitare il volume dei dati. Si consiglia di iniziare con un periodo da 3 a 6 mesi.
Avvii il processo di esportazione: Dopo aver configurato tutte le entità e i filtri, selezioni Export nel riquadro delle azioni. Il sistema creerà un pacchetto di processo e avvierà l’elaborazione. Può controllarne l’avanzamento nella sezione Job history.
Scarichi il pacchetto di dati: Al termine del processo di esportazione, apra i dettagli in Job history e selezioni Download package. Verrà scaricato un file ZIP contenente i file di dati separati per ciascuna entità.
Trasformi i dati grezzi in un Event Log: I file esportati rappresentano tabelle di sistema grezze, non un Event Log pronto all’uso. Per unire e riorganizzare i dati, è necessario utilizzare uno strumento esterno come Python, Power Query o una piattaforma ETL. Le operazioni comprendono:
- Unire i file delle intestazioni e delle righe.
- Unire i dati del Workflow alle richieste utilizzando CorrelationId e RecId dell’intestazione della richiesta d’acquisto.
- Trasformare le modifiche di stato e gli eventi del Workflow presenti nelle tabelle Workflow in righe distinte per ciascuna attività (Requisition Submitted, Approval Step Approved e così via).
- Creare una nuova riga per ogni attività, con i valori corretti di ActivityName, EventTime e PurchaseRequisitionId.
Calcoli e mappatura degli attributi: Durante la trasformazione, mappi le colonne di origine sugli attributi richiesti, come Utente e Reparto. Calcoli gli attributi derivati, ad esempio 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 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 e includere PurchaseRequisitionId, ActivityName e EventTime.

Configurazione

Autorizzazioni richieste: Gli utenti devono disporre di un ruolo di sicurezza con autorizzazioni per l’area di lavoro Data management e accesso alle specifiche entità dati da esportare, ad esempio Data management administrator o un ruolo personalizzato equivalente.
Entità dati principali:
- Purchase requisition headers: fornisce l’identificativo principale del caso, la data e ora di creazione e lo stato complessivo.
- Purchase requisition lines: contiene i dettagli di ciascun articolo richiesto, inclusi gli importi e i collegamenti agli ordini d’acquisto.
- Workflow tracking status table: è la fonte principale degli eventi del Workflow, come invio, approvazione, rifiuto e richiamo.
- Workflow work items: descrive le attività specifiche assegnate agli utenti durante il processo di approvazione.
- Purchase order lines V2: consente di individuare la data e ora di creazione dell’ordine d’acquisto collegato a una riga della richiesta.
Filtro per 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 si consiglia un periodo da 3 a 6 mesi, così da bilanciare il volume dei dati e le informazioni ricavabili sul processo.
Filtro per codice società: Applichi sempre un filtro per Legal entity per evitare di estrarre dati da società non pertinenti o di test. In questo modo si riduce notevolmente la quantità di dati e si migliorano le prestazioni del processo di esportazione.
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. È necessario utilizzare uno strumento di scripting o ETL.

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, che verrà utilizzata per autenticarsi con l’API Dynamics 365. Prenda nota dell’ID applicazione (client) e dell’ID directory (tenant).
Generi un segreto client: Nell’applicazione appena registrata in Azure, crei un nuovo segreto client in 'Certificates & secrets'. Copi e conservi il valore del segreto in modo sicuro, poiché non sarà più visibile in seguito.
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’autorizzazione equivalente più restrittiva, di sola lettura. Conceda il consenso amministrativo per le autorizzazioni.
Installi le librerie Python: Verifichi che Python sia installato, quindi installi le librerie necessarie con 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 società.
Esamini 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 d’acquisto, e WorkflowTrackingStatusTable per tutti gli eventi relativi al Workflow, come invii e approvazioni.
Esegua lo script: Avvii lo script dalla riga di comando: python extract_d365_requisitions.py. Lo script eseguirà l’autenticazione, recupererà i dati per ciascuna attività e gestirà automaticamente la paginazione dell’API.
Trasformazione dei dati: Lo script elabora i dati JSON grezzi restituiti dalle chiamate API. Riorganizza 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.
Unisca e standardizzi gli eventi: Tutti gli eventi generati vengono raccolti in un unico elenco e 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 essere caricato direttamente in uno strumento di Process Mining. Verifichi che la codifica sia UTF-8.

Configurazione

Prerequisiti: Accesso a una sottoscrizione Azure per registrare un’applicazione. Servono 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 OData dell’API 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 l’intervallo di estrazione. Per l’analisi iniziale si consiglia un periodo da 3 a 6 mesi, così da bilanciare il volume dei dati e le informazioni ricavabili.
Filtro per società: Lo script è configurato per filtrare una specifica entità giuridica tramite 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: Nelle query OData, lo script utilizza $select per recuperare solo le colonne necessarie all’Event Log, migliorando così le prestazioni. Gestisce inoltre la paginazione per elaborare grandi set di dati senza sovraccaricare l’API. Per caricare grandi volumi di dati storici, può eseguire lo script in più batch, utilizzando intervalli di date più brevi.

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 sia autorizzato ad accedere alle entità dati necessarie, alla cronologia del Workflow, ai dati delle richieste e ai dati correlati degli ordini d’acquisto.
In Power BI Desktop, selezioni Get data, scelga il connettore Microsoft Dynamics 365 Finance e inserisca l’URL dell’istanza Dynamics 365 Finance. Si autentichi con un account autorizzato a leggere le entità necessarie. Sostituisca [Your Dynamics 365 Finance instance URL] con l’URL dell’istanza del proprio ambiente.
In Navigator, selezioni le entità delle intestazioni e delle righe delle richieste d’acquisto, quelle della cronologia o del monitoraggio del Workflow, le entità di utenti e organizzazioni e quelle degli ordini d’acquisto richieste dalla propria implementazione. I nomi delle entità e i campi disponibili variano a seconda dell’ambiente. Consulti i metadati delle entità e sostituisca ogni segnaposto nella query con l’entità e il campo corrispondenti esposti dal sistema.
Carichi le entità selezionate in Power Query. Filtri i dati in base all’entità giuridica o alla società, al tipo di documento e al periodo di estrazione richiesti. Utilizzi i parametri [Start date] e [End date] e mantenga i record la cui data e ora dell’evento rientra nel periodo selezionato. Includa i record creati prima della data iniziale se presentano eventi del Workflow o di chiusura nel periodo, così da mantenere completa la cronologia dei casi.
Standardizzi gli identificativi e le date e ore. Converta in testo l’identificativo della richiesta d’acquisto, uniformi tutte le date e ore degli eventi a un unico fuso orario, UTC o quello aziendale, e mantenga la precisione originale delle date e ore. Verifichi che l’identificativo dell’intestazione della richiesta sia presente in ogni riga di evento. Se i record del Workflow contengono solo un identificativo di correlazione del Workflow, li unisca all’intestazione della richiesta utilizzando la relazione documentata e configurata nell’ambiente.
Crei una query di eventi per ciascuna attività richiesta. Le query 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 si affidi a ProcessMind per dedurre attività dalle modifiche di stato o dall’ordine degli eventi.
Per Requisition Amended, applichi la logica documentata di richiamo e nuovo invio ricavata dalla cronologia del Workflow. Un’azione di richiamo seguita da un invio successivo deve generare un evento di modifica all’ora del richiamo oppure all’ora della modifica esposta dall’entità di origine. Non crei una riga di modifica basandosi unicamente su un cambiamento dello stato della richiesta, a meno che il sistema di origine non registri esplicitamente tale cambiamento come modifica.
Per gli eventi delle righe e degli ordini d’acquisto, unisca le righe delle richieste alle righe degli ordini d’acquisto utilizzando la relazione documentata nell’origine. Se l’Event Log è basato sui casi identificati da PurchaseRequisitionId, aggreghi gli eventi a livello di riga oppure li mantenga come righe separate con lo stesso identificativo del caso. Se disponibili, conservi gli identificativi delle righe in colonne aggiuntive, 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. Per i valori non disponibili utilizzi null, senza inventare dati, e imposti per SourceSystemId un valore di origine coerente, come Dynamics 365 Finance.
Accodi tutte le query delle attività con UNION ALL, rimuova le righe prive dell’identificativo del caso o della data e ora dell’evento e ordini i dati per PurchaseRequisitionId ed EventTime. Mantenga gli eventi duplicati quando rappresentano attività distinte del Workflow o righe separate della richiesta. Rimuova i duplicati solo quando è possibile dimostrare che i record di origine sono estrazioni duplicate.
Convalidi l’Event Log risultante utilizzando i controlli descritti di seguito. Verifichi che ogni attività richiesta sia rappresentata da righe esplicite, che le date e ore rientrino nel periodo selezionato e che le unioni 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 data e ora dell’evento. Mantenga SourceSystemId e LastDataIngestionTimestamp come attributi dell’evento e conservi, se disponibili, tutti gli attributi consigliati.

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. Verifichi i nomi delle entità e dei campi nei metadati di Navigator per l’implementazione specifica.
Entità richieste: Selezioni le entità delle intestazioni e delle righe delle richieste d’acquisto, quelle di monitoraggio o cronologia del Workflow, le entità delle intestazioni e delle righe degli ordini d’acquisto e quelle di utenti o organizzazioni necessarie per arricchire i dati. Utilizzi i segnaposto [Your entity name] finché non saranno confermate le entità esatte.
Intervallo di date: Inizi con un periodo da tre a sei mesi. Includa le intestazioni storiche delle richieste relative ai casi che presentano eventi del Workflow, degli ordini d’acquisto, di chiusura delle righe o di chiusura della richiesta nel periodo selezionato.
Filtri per società e documento: Applichi, se pertinenti, i filtri [Your company or legal entity filter] e [Your document type filter]. Verifichi se l’identificativo della richiesta è univoco a livello globale o solo all’interno di una società.
Ambito del Workflow: Includa le azioni di invio, richiamo, nuovo invio, assegnazione delle attività, approvazione, rifiuto, ritiro, completamento e annullamento. Configuri la mappatura delle azioni e degli stati del Workflow in base ai valori utilizzati nell’ambiente.
Semantica degli eventi: Ogni attività deve essere registrata come riga di evento esplicita. ProcessMind non deduce eventi di approvazione, modifica, chiusura o conversione da altre righe.
Gestione delle date e ore: Uniformi tutte le date e ore a un unico fuso orario. Documenti se i valori di origine sono memorizzati in UTC o nell’ora locale aziendale. Utilizzi il valore di origine con la massima precisione disponibile.
Aggiornamento incrementale: Per le estrazioni ricorrenti, utilizzi come riferimento il valore massimo della data e ora di modifica o dell’evento nell’origine, prevedendo un intervallo di sovrapposizione per acquisire i record del Workflow arrivati in ritardo. Riconcili i dati dell’intervallo sovrapposto prima di caricare l’Event Log finale.
Prestazioni: Applichi i filtri alle entità di origine prima delle unioni, selezioni solo le colonne necessarie, eviti di caricare dati storici del Workflow non necessari e utilizzi il query folding, se supportato. Estragga separatamente intestazioni, righe, eventi del Workflow e relazioni con gli ordini d’acquisto prima di combinarli.
Autorizzazioni e prerequisiti: L’account deve poter leggere le entità dati selezionate di Dynamics 365 Finance e i dati del Workflow. Verifichi che siano abilitate le funzionalità pertinenti per gli acquisti e il Workflow e che Power BI Desktop, il connettore, la configurazione del gateway, se applicabile, e le politiche di sicurezza aziendali consentano l’estrazione.
Valuta e importi: Verifichi quale valuta è rappresentata da RequisitionTotalAmount. Se le richieste possono includere più valute, aggiunga la valuta di origine come attributo e non converta gli importi senza indicarlo.
Gestione dei valori null: Gli attributi consigliati possono essere null se il sistema di origine non memorizza un valore, se le autorizzazioni ne limitano l’accesso o se non è possibile risolvere la relazione. Prima dell’esportazione, verifichi la presenza dei valori obbligatori relativi a caso, attività e data e ora dell’evento.

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

Con questo template ha tutto ciò che serve per iniziare a ottimizzare il processo Purchase-to-Pay - Richieste di acquisto. Inizi oggi a individuare informazioni utili.

Torna alla guida al miglioramento

Scarica il template

Ottimizzi il processo Purchase to Pay - Requisition per accelerare le approvazioni

Elimini i ritardi e riduca del 30% i tempi di ciclo in Dynamics 365.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.

Il Suo template di dati per Purchase-to-Pay - Richieste di acquisto

Il Suo template di dati per Purchase-to-Pay - Richieste di acquisto

Attributi di Purchase-to-Pay - Richieste di acquisto

Attività di Purchase-to-Pay - Richieste di acquisto

Guide all’estrazione

Esportazione tramite Data Management Framework di Dynamics 365

Passaggi

Configurazione

Query di esempio sql

Script Python con API REST OData di Dynamics 365

Passaggi

Configurazione

Query di esempio python

Estrazione con il connettore nativo di Microsoft Power BI

Passaggi

Configurazione

Query di esempio sql

È pronto a iniziare?

Ottimizzi il processo Purchase to Pay - Requisition per accelerare le approvazioni