> Amélioration continue des processus > Purchase to Pay Requisition > Oracle Fusion Financials > Modèle de données

Votre modèle de données Purchase to Pay - Requisition

Oracle Fusion Financials

Purchase to Pay - Requisition : attributs (22) Purchase to Pay - Requisition : activités (12) Guides d’extraction (4)

Votre modèle de données Purchase to Pay - Requisition

Ce modèle fournit une feuille de route claire pour recueillir les données essentielles à l’analyse de votre processus Purchase to Pay - Requisition. Il présente les principaux attributs à collecter, les activités importantes à suivre et des indications pratiques pour extraire ces informations d’Oracle Fusion Financials. Vous pouvez ainsi préparer efficacement votre journal d’événements au Process Mining.

Attributs recommandés à collecter
Activités importantes à suivre
Recommandations d’extraction pour Oracle Fusion Financials

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Purchase to Pay - Requisition : attributs

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail le processus Purchase to Pay - Requisition.

5 Obligatoire 7 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l’événement métier qui s’est produit à un moment précis du processus de demande d’achat.
Description L’activité représente une étape ou une étape clé distincte du cycle de vie d’une demande d’achat. Parmi les exemples figurent « Requisition Created », « Approval Step Approved » et « Purchase Order Created ». Ces activités sont déduites des changements de statut, des actions des utilisateurs ou des événements système enregistrés dans les journaux d’audit ou les tables de transactions du système source. Cet attribut est essentiel pour construire la carte de processus, qui représente visuellement le flux des demandes d’achat. L’analyse de la séquence et de la fréquence des activités permet d’identifier les parcours courants, les goulots d’étranglement, les boucles de reprise et les écarts par rapport à la procédure standard. Pourquoi c’est important Il constitue la structure de base de la cartographie du processus et permet de visualiser et d’analyser le flux de travail de la demande. Où les obtenir Dérivé des enregistrements de changement de statut dans des tables telles que POR_REQUISITION_HEADERS_ALL, de l’historique des transactions ou de pistes d’audit du flux de travail telles que FA_FUSION_SOAINFRA.WFTASK. Exemples Demande crééeÉtape d’approbation approuvéeDemande d’achat rejetéeBon de commande créé
	Heure de l’événement EventTime	Horodatage indiquant le moment où l’activité s’est produite.
Description L’heure de l’événement enregistre la date et l’heure précises auxquelles une activité donnée s’est produite. Cet horodatage est fondamental pour classer chronologiquement les événements d’un cas. Il provient des dates de création, des dates de dernière mise à jour ou des horodatages associés à des actions précises dans le système. Dans l’analyse, l’heure de l’événement sert à calculer toutes les métriques fondées sur la durée, comme les délais entre les activités, les temps d’attente et la durée globale d’un cas. Elle est essentielle pour identifier les goulots d’étranglement, mesurer la performance par rapport aux SLA et comprendre la dynamique temporelle du processus de demande d’achat. Pourquoi c’est important Cet attribut est essentiel pour calculer tous les KPI liés au temps, classer correctement les événements et analyser la performance ainsi que les goulots d’étranglement du processus. Où les obtenir Ces informations proviennent généralement d’une colonne « LAST_UPDATE_DATE » ou « CREATION_DATE » associée à la transaction ou au changement de statut, souvent dans des tables telles que POR_REQUISITION_HEADERS_ALL ou dans les tables d’historique du flux de travail. Exemples 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	Identifiant de demande d’achat PurchaseRequisitionId	Identifiant unique d’une demande d’achat, utilisé comme identifiant de cas pour le processus.
Description L’identifiant de demande d’achat est l’identifiant central qui relie toutes les activités associées à une demande précise de biens ou de services. Chaque demande d’achat reçoit un identifiant unique lors de sa création, qui reste inchangé pendant tout son cycle de vie. Dans le Process Mining, cet attribut sert à regrouper dans un même cas tous les événements associés, comme la création, la soumission, les étapes d’approbation et la clôture finale. Il permet ainsi d’analyser le parcours complet de la demande d’achat, de visualiser les cartes de processus, de calculer les délais de cycle et d’analyser les variantes de chaque demande. Pourquoi c’est important Il s’agit de l’attribut fondamental pour suivre le cycle de vie d’une demande d’achat de bout en bout, et pour réaliser toutes les analyses au niveau des cas ainsi que les calculs de KPI. Où les obtenir Il s’agit généralement de la clé primaire de la table d’en-tête des demandes d’achat, par exemple POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID dans Oracle Fusion Financials. Exemples 100234810023491002350
	Dernière mise à jour des données LastDataUpdate	Horodatage de l’actualisation la plus récente des données provenant du système source.
Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis Oracle Fusion Financials. Il s’applique à l’ensemble du jeu de données et non à des événements individuels. Les analystes utilisent cette information pour évaluer l’actualité des données et vérifier à quel moment les dernières transactions ont été incluses. Il s’agit d’un élément de métadonnées important pour les rapports des Dashboards et pour garantir que les analyses reposent sur des informations à jour. Pourquoi c’est important Informe les utilisateurs sur l’actualité des données et garantit que les analyses restent pertinentes et reposent sur les informations les plus récentes disponibles. Où les obtenir Cet horodatage est généré et enregistré lors de l’extraction des données, généralement par l’outil ETL ou le pipeline de données. Exemples 2023-10-27T02:00:00Z
	Système source SourceSystem	Système d’information à partir duquel ces données ont été extraites.
Description Cet attribut identifie l’origine des données du processus. Pour ce modèle de données, sa valeur sera toujours « Oracle Fusion Financials ». Dans les environnements qui utilisent plusieurs ERP ou systèmes intégrés, ce champ est essentiel pour assurer la traçabilité des données, résoudre les problèmes et garantir leur qualité. Il fournit le contexte nécessaire pour identifier la source de référence des événements du processus analysé. Pourquoi c’est important Fournit un contexte essentiel sur l’origine des données, ce qui est important pour leur gouvernance et pour l’intégration de données provenant de plusieurs systèmes. Où les obtenir Il s’agit d’une valeur statique ajoutée lors de l’extraction et de la transformation des données afin d’indiquer l’origine du jeu de données. Exemples Oracle Fusion Financials
	Date requise RequiredByDate	Date à laquelle les biens ou services sont nécessaires au demandeur.
Description Cette date est indiquée par le demandeur pour préciser la date limite de réception des articles demandés. Elle sert de cible interne de niveau de service (SLA) pour le processus d’achat. Cet attribut constitue la base du Dashboard « Performance par rapport à la date requise » et du KPI « Taux de respect de la date requise ». En comparant cette date à la date réelle de création du bon de commande ou de réception des biens, l’analyse peut montrer dans quelle mesure le processus d’achat répond aux besoins des clients internes et mettre en évidence les retards systémiques. Pourquoi c’est important Essentiel pour mesurer la performance du processus par rapport aux échéances internes et déterminer si le processus d’achat répond aux besoins de l’entreprise dans les délais. Où les obtenir Généralement stocké au niveau de la ligne de la demande d’achat, dans des tables telles que POR_REQUISITION_LINES_ALL, dans un champ comme « NEED_BY_DATE ». Exemples 2023-11-012023-12-152024-01-31
	Montant total de la demande d’achat RequisitionTotalAmount	Valeur monétaire totale de la demande d’achat.
Description Cet attribut représente la somme de la valeur de toutes les lignes d’une demande d’achat. Il s’agit d’une information essentielle pour comprendre l’importance financière de chaque demande. Dans le Process Mining, le montant total sert à de nombreuses analyses. Il permet notamment de filtrer les demandes d’achat de montant élevé, qui suivent souvent des parcours d’approbation différents ou font l’objet d’un contrôle plus strict. Les Dashboards peuvent utiliser cet attribut pour analyser la corrélation entre des indicateurs du processus, comme le délai de cycle ou le taux de rejet, et la valeur de la demande d’achat. Pourquoi c’est important Fournit un contexte financier qui permet d’analyser les demandes selon leur valeur, de prioriser les améliorations du processus et de comprendre l’influence du montant sur le comportement du processus. Où les obtenir Situé dans l’en-tête de la demande d’achat, souvent dans un champ tel que REQUISITION_TOTAL de POR_REQUISITION_HEADERS_ALL. Il peut également être calculé en additionnant les montants des lignes de POR_REQUISITION_LINES_ALL. Exemples 550.0012500.7599.99
	Motif du rejet RejectionReason	Motif fourni par un approbateur lorsqu’une demande d’achat ou une étape d’approbation est rejetée.
Description Lorsqu’une demande d’achat est rejetée, l’approbateur fournit généralement un motif, soit en sélectionnant une valeur dans une liste prédéfinie, soit en saisissant un texte libre. Cet attribut enregistre cette justification. Il est essentiel pour analyser les causes profondes des échecs du processus. Il alimente directement le Dashboard « Tendances des modifications et des rejets » en expliquant les raisons des rejets. L’analyse des motifs de rejet permet d’identifier les problèmes récurrents, comme un codage incorrect, des dépassements budgétaires ou des violations de règles, qui peuvent ensuite être traités par la formation ou par des contrôles système. Pourquoi c’est important Fournit une analyse directe des raisons pour lesquelles les demandes d’achat sont rejetées, ce qui permet de cibler les améliorations afin de réduire les reprises et d’augmenter le taux de traitement direct. Où les obtenir Extrait des commentaires du flux de travail ou des champs contenant les codes de motif de rejet dans la piste d’audit du flux de travail, potentiellement dans les tables liées à FA_FUSION_SOAINFRA.WFTASK ou dans le stockage associé aux commentaires. Exemples Compte général incorrectBudget du centre de coûts dépasséFournisseur non privilégié sélectionnéDemande en double
	Nom du demandeur RequesterName	Nom du collaborateur qui a créé et soumis la demande d’achat.
Description Cet attribut identifie la personne à l’origine de la demande de biens ou de services. Cette information est généralement recueillie au début du processus, lors de la création de la demande d’achat. L’analyse de la performance du processus par demandeur est essentielle pour le Dashboard « Indicateurs de performance des demandeurs ». Elle permet d’identifier les utilisateurs ou les groupes qui pourraient avoir besoin d’une formation complémentaire, en mettant en évidence les taux élevés de modification ou de rejet ainsi que les délais de cycle importants associés à leurs demandes. Elle apporte une vision du processus centrée sur les personnes. Pourquoi c’est important Permet d’analyser la performance par demandeur, d’identifier les besoins de formation et de mettre en évidence les utilisateurs ou les services les plus efficaces. Où les obtenir Provient des données d’en-tête de la demande d’achat, souvent en reliant l’identifiant du demandeur à une table de référence des collaborateurs ou des utilisateurs. Recherchez les champs associés à « PREPARER_ID » dans POR_REQUISITION_HEADERS_ALL et effectuez une jointure avec PER_ALL_PEOPLE_F. Exemples John SmithJane DoeEmily Jones
	Service DepartmentName	Service de l’entreprise auquel appartient le demandeur.
Description Cet attribut indique l’unité organisationnelle de la personne qui a créé la demande d’achat, par exemple « Finance », « IT » ou « Marketing ». Il est généralement dérivé du profil utilisateur du demandeur dans le système RH. L’analyse par service est une méthode courante et efficace pour segmenter les données du processus. Elle permet d’identifier des comportements propres à certains services, comme des taux de rejet plus élevés ou des délais de cycle plus longs, afin de cibler les initiatives d’amélioration. Il s’agit d’une dimension importante du Dashboard « Indicateurs de performance des demandeurs ». Pourquoi c’est important Permet d’analyser le processus par unité opérationnelle et de révéler les tendances, les performances et les problèmes de conformité propres à chaque service. Où les obtenir Généralement dérivé du profil du demandeur, avec une jointure entre la table des demandes d’achat et une table RH ou un annuaire des utilisateurs contenant les informations sur le service. Exemples Technologies de l’informationFinanceOpérationsMarketing
	Statut de la demande d’achat RequisitionStatus	Statut actuel ou final de la demande d’achat.
Description Cet attribut indique l’état global de la demande d’achat à un moment donné ou son résultat final, par exemple « Approved », « Rejected », « In Process » ou « Closed ». Il constitue souvent la source à partir de laquelle de nombreuses activités du journal d’événements sont déduites. Cet attribut est essentiel pour le Dashboard « Vue d’ensemble du statut des demandes d’achat », qui fournit un aperçu de la charge de travail et du backlog actuels. Il sert également à calculer des KPI fondés sur les résultats, comme le taux de rejet des demandes d’achat, en filtrant les cas qui se terminent par un statut donné. Pourquoi c’est important Fournit un aperçu de l’état actuel des demandes d’achat et sert à déterminer les résultats finaux pour le calcul des KPI. Où les obtenir Présent dans la table d’en-tête de la demande d’achat, généralement dans un champ tel que « DOCUMENT_STATUS » ou « APPROVAL_STATUS » de POR_REQUISITION_HEADERS_ALL. Exemples APPROUVÉEEN COURSREJETÉERETIRÉE
	Unité opérationnelle BusinessUnit	Unité opérationnelle précise de l’organisation à laquelle appartient la demande d’achat.
Description L’unité opérationnelle représente une entité juridique ou fonctionnelle distincte de l’entreprise pour laquelle la demande d’achat est effectuée. Il s’agit d’un regroupement organisationnel de niveau supérieur à celui d’un service. L’analyse des données par unité opérationnelle permet de comparer les performances à un niveau global entre différentes parties de l’organisation. Elle aide la direction à déterminer si les inefficacités du processus sont localisées ou généralisées, et à cibler les efforts d’amélioration. Il s’agit d’une dimension essentielle pour filtrer la plupart des Dashboards et des KPI. Pourquoi c’est important Fournit un contexte organisationnel de haut niveau, qui permet de comparer les performances et de mener des analyses stratégiques entre les différentes entités de l’entreprise. Où les obtenir Il s’agit d’un champ organisationnel fondamental dans Oracle Fusion, généralement disponible dans l’en-tête de la demande d’achat, dans des tables telles que POR_REQUISITION_HEADERS_ALL. Exemples BU Amérique du NordBU EuropeSiège social
	Chemin du flux de travail d’approbation ApprovalWorkflowPath	Séquence prédéfinie des approbateurs ou des groupes d’approbation requis pour la demande d’achat.
Description Cet attribut définit le processus d’approbation standard attendu pour une demande donnée, conformément aux politiques de l’entreprise et en tenant compte de facteurs tels que le montant, le type et le service. Il représente le modèle de processus « to-be ». Le chemin du flux de travail d’approbation est fondamental pour la conformité et l’analyse de la conformité. Il alimente directement le Dashboard « Compliance and Deviation Analysis » et le KPI « Requisition Conformance Index », en permettant de comparer les étapes d’approbation réellement suivies au chemin prescrit. Les écarts peuvent révéler des violations de politiques ou des inefficacités du processus. Pourquoi c’est important Permet de vérifier la conformité en comparant le flux réel du processus à la hiérarchie d’approbation requise et en mettant en évidence les demandes d’achat non conformes. Où les obtenir Ces informations sont configurées dans la BPM Worklist d’Oracle Fusion ou dans l’Approval Management Engine (AMX). L’extraction du parcours défini pour chaque demande d’achat peut être complexe et nécessiter l’interrogation de tables de configuration. Exemples Responsable > Directeur > Vice-président FinanceResponsable du centre de coûts > Sécurité informatiqueResponsable > Responsable de département
	Description de l’article ItemDescription	Description du produit ou du service demandé sur une ligne de demande d’achat.
Description Cet attribut contient la description textuelle de l’article acheté. Il fournit des informations précises sur les biens ou services demandés. Bien qu’elle soit souvent non structurée, la description de l’article apporte un contexte utile à l’analyse. Elle peut servir de filtre pour isoler des demandes d’achat correspondant à certains types d’achats qui ne sont pas nécessairement couverts par le type de demande d’achat. Par exemple, un analyste peut rechercher toutes les demandes contenant « Software License » afin d’étudier leur parcours et leur délai de cycle spécifiques. Pourquoi c’est important Fournit un contexte détaillé sur l’achat effectué et permet un filtrage ainsi qu’une analyse plus précis de biens ou de services particuliers. Où les obtenir Situé dans la table des lignes de demande d’achat, POR_REQUISITION_LINES_ALL, dans un champ tel que ITEM_DESCRIPTION. Exemples Ordinateur portable 15 pouces, 16 Go de RAMServices de conseil - Projet du 4e trimestreRenouvellement annuel de la maintenance logicielle
	Devise CurrencyCode	Code de la devise du montant de la demande d’achat, par exemple USD ou EUR.
Description Cet attribut précise la devise dans laquelle est exprimé le montant total de la demande d’achat. Dans les organisations internationales, les demandes peuvent être créées dans différentes devises. Il est indispensable pour interpréter et agréger correctement les données financières. Dans toute analyse portant sur des montants, le code devise doit être utilisé pour garantir une comparaison exacte, soit en filtrant une seule devise, soit en convertissant tous les montants dans une devise commune. Pourquoi c’est important Garantit l’exactitude des analyses et des rapports financiers, notamment dans les organisations internationales qui utilisent plusieurs devises. Où les obtenir Généralement présent dans la table d’en-tête de la demande d’achat, à côté des champs de montant, par exemple dans POR_REQUISITION_HEADERS_ALL. Exemples USDEURGBPJPY
	Est automatisé IsAutomated	Indicateur précisant si une activité a été exécutée automatiquement par le système.
Description Cet attribut identifie les événements du processus exécutés par un utilisateur système ou un agent automatisé plutôt que par une personne. Il peut s’agir, par exemple, de changements de statut déclenchés par le système ou d’étapes d’approbation automatisées pour les demandes de faible montant. L’analyse de cet attribut permet de mesurer le niveau d’automatisation du processus. Elle peut servir à comparer la rapidité et l’efficacité des étapes automatisées et manuelles, ainsi qu’à identifier de nouvelles possibilités d’automatisation. Pourquoi c’est important Aide à mesurer le niveau d’automatisation du processus et à identifier les possibilités d’automatiser les tâches manuelles. Où les obtenir Obtenu en vérifiant si l’utilisateur associé à une activité est un compte système ou un compte de service. Cette vérification nécessite une liste des identifiants connus des utilisateurs système. Exemples truefalse
	Est modifiée IsAmendedFlag	Indicateur booléen qui vaut true si la demande d’achat a été modifiée au moins une fois.
Description Cet attribut calculé indique si une demande d’achat a subi des modifications après sa soumission initiale. Il est obtenu en vérifiant la présence d’une activité « Requisition Amended » dans l’historique du cas. Ce indicateur simplifie l’analyse et le calcul des KPI. Il est utilisé directement pour calculer le KPI « Requisition Amendment Rate » et identifier les cas qui ne suivent pas un traitement de bout en bout. Il facilite le filtrage et la comparaison des indicateurs de processus entre les demandes d’achat modifiées et non modifiées. Pourquoi c’est important Simplifie le calcul du taux de modification et facilite la comparaison des demandes d’achat modifiées et non modifiées. Où les obtenir Cet attribut n’existe pas dans le système source, mais il est calculé lors de la transformation des données en fonction de la présence d’activités liées aux modifications dans l’Event Log. Exemples truefalse
	Nom de l’utilisateur UserName	Nom de l’utilisateur qui a effectué une activité précise, par exemple un approbateur ou un éditeur.
Description Alors que le nom du demandeur identifie l’initiateur, le nom de l’utilisateur désigne la personne qui a exécuté un événement précis du processus, comme une approbation ou un rejet. Cet attribut est particulièrement important dans les Workflows d’approbation à plusieurs étapes, auxquels participent plusieurs personnes. Il est essentiel pour analyser les goulots d’étranglement des approbations et mesurer la performance d’approbateurs ou d’équipes précis. Il alimente directement le Dashboard « Goulots d’étranglement du Workflow d’approbation », en permettant d’analyser les délais de traitement de chaque utilisateur intervenant dans la chaîne d’approbation. Pourquoi c’est important Identifie l’acteur associé à chaque événement, ce qui est indispensable pour analyser les délais de transmission, la performance des approbateurs et l’affectation des ressources. Où les obtenir Extrait des tables d’historique du flux de travail ou des tables de piste d’audit, telles que FA_FUSION_SOAINFRA.WFTASK, qui enregistrent l’utilisateur associé à l’achèvement de chaque tâche. Exemples David LeeSusan ChenMichael Brown
	Nom du fournisseur SupplierName	Nom du fournisseur suggéré ou présélectionné pour les biens ou services.
Description Cet attribut identifie le fournisseur auprès duquel les biens ou services doivent être achetés. Le fournisseur peut être suggéré par le demandeur ou déterminé par le système à partir de catalogues ou d’accords existants. L’analyse par fournisseur peut révéler des tendances importantes dans les achats. Elle peut par exemple montrer si les demandes destinées à certains fournisseurs prennent plus de temps à être approuvées ou présentent des taux de rejet plus élevés. Ces informations peuvent être utiles à la gestion des relations fournisseurs et à la stratégie d’achat. Pourquoi c’est important Permet d’analyser la performance du processus par fournisseur, ce qui peut contribuer à la stratégie de sourcing et à la gestion des relations fournisseurs. Où les obtenir Situé dans la table des lignes de demande d’achat, POR_REQUISITION_LINES_ALL, souvent relié par l’intermédiaire de VENDOR_ID à une table de référence des fournisseurs telle que POZ_SUPPLIERS. Exemples Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
	Numéro du bon de commande PurchaseOrderNumber	Identifiant du bon de commande créé à partir de la demande d’achat approuvée.
Description Cet attribut relie une demande d’achat au bon de commande qui en découle. Une fois la demande d’achat entièrement approuvée, elle est généralement convertie en un ou plusieurs bons de commande à envoyer à un fournisseur. Dans l’analyse, cet identifiant est essentiel pour suivre le processus en aval de la demande d’achat. Il permet de calculer le KPI « Délai entre la demande d’achat et le bon de commande » et alimente le Dashboard « Délai de cycle entre la demande d’achat et le bon de commande ». Il permet également de combiner les données du processus de demande d’achat avec les processus ultérieurs de commande et de facturation, pour une analyse Purchase-to-Pay réellement de bout en bout. Pourquoi c’est important Relie la demande d’achat au bon de commande qui lui fait suite, ce qui permet de mesurer le délai entre la demande d’achat et le bon de commande et d’analyser le processus de bout en bout. Où les obtenir Cette information est enregistrée une fois le bon de commande créé. Elle se trouve généralement en recherchant les références à la demande d’achat d’origine dans les tables de distribution des bons de commande, telles que PO_DISTRIBUTIONS_ALL, qui renvoient à la ligne de demande d’achat. Exemples PO-2023-5832PO-2023-5833PO-2023-5834
	Suit un traitement de bout en bout IsStraightThrough	Indicateur précisant si la demande d’achat a été approuvée sans modification ni rejet.
Description Cet indicateur calculé identifie les demandes d’achat qui ont suivi le processus, de la soumission à l’approbation, sans boucle de reprise, comme une modification ou un rejet. Il signale qu’un cas a été traité parfaitement. Cet attribut constitue la base du KPI « Straight-Through Requisition Rate ». L’analyse des caractéristiques des demandes d’achat traitées de bout en bout, par exemple les services, les demandeurs ou les types concernés, peut révéler des bonnes pratiques et des possibilités d’automatisation. À l’inverse, l’analyse des demandes qui ne suivent pas ce parcours permet d’identifier les principales sources d’inefficacité. Pourquoi c’est important Mesure directement l’efficacité du processus et sert de base au KPI « Straight-Through Requisition Rate », afin d’identifier les sources de reprise. Où les obtenir Cet attribut est calculé lors de la transformation des données. Un cas est défini comme vrai si aucune activité « Requisition Amended » ni « Approval Step Rejected » n’est présente. Exemples truefalse
	Type de demande d’achat RequisitionType	Catégorie de la demande d’achat, par exemple une demande de biens ou de services.
Description Cet attribut classe la demande selon l’objet de la demande. Les types courants comprennent les biens, les services ou les dépenses d’investissement. Le type peut influer sur le flux de travail d’approbation requis et sur la stratégie d’achat. Dans l’analyse, Requisition Type constitue une dimension utile pour le filtrage et la comparaison. Vous pouvez par exemple vérifier si les demandes de services présentent un temps de cycle d’approbation plus long que les demandes de biens. Cet attribut aide à déterminer si les différents types de demandes présentent des comportements ou des goulots d’étranglement distincts. Pourquoi c’est important Permet de segmenter l’analyse afin de comprendre en quoi le processus diffère selon les types d’achats, par exemple entre les biens et les services. Où les obtenir Il est souvent déterminé par le type ou la catégorie de ligne sélectionné lors de la création de la demande d’achat. Il peut être stocké dans la table des lignes de demande d’achat, POR_REQUISITION_LINES_ALL. Exemples BiensServicesDépense d’investissement

Obligatoire Recommandé Facultatif

Purchase to Pay - Requisition : activités

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour découvrir précisément votre processus Purchase to Pay - Requisition.

6 Recommandé 6 Facultatif

	Activité	Description
	Bon de commande créé	Cet événement se produit lorsqu’une ligne de demande d’achat approuvée sert à générer un bon de commande. Il relie le processus de demande d’achat au processus d’achat en aval.
Pourquoi c’est important Il s’agit d’une étape essentielle pour mesurer le délai entre la demande d’achat et le bon de commande. Les retards à ce stade indiquent des goulots d’étranglement lors du passage de l’approbation aux achats. Où les obtenir Il s’agit d’un événement explicite. Le lien entre la demande d’achat et le bon de commande est stocké dans des tables telles que PO_LINE_LOCATIONS_ALL, qui contient une référence à l’identifiant de la ligne de demande d’achat source. Collecte Recherchez la date de création du bon de commande qui fait référence à l’identifiant de demande d’achat indiqué. Type d’événement explicit
	Demande créée	Marque le début du processus achats lorsqu’un utilisateur enregistre une nouvelle demande d’achat pour la première fois. Cet événement est généralement enregistré explicitement, avec un horodatage correspondant dans le système.
Pourquoi c’est important Il s’agit de l’événement de début principal du processus de demande. L’analyse du temps écoulé entre la création et la soumission peut révéler des retards dans la formalisation de la demande. Où les obtenir Cet événement est enregistré dans la table POR_REQUISITION_HEADERS_ALL, à partir de la colonne creation_date lors de la génération d’un nouvel identifiant de demande. Collecte Utilisez l’horodatage de création de l’enregistrement d’en-tête de la demande. Type d’événement explicit
	Demande d’achat approuvée	Marque l’approbation finale de la demande d’achat après le franchissement réussi de toutes les étapes du flux de travail. Cet événement est déduit du passage du statut global de la demande à « Approved ».
Pourquoi c’est important Il s’agit d’une étape essentielle, qui indique que la demande est prête à être traitée par les achats. Elle marque la fin de la mesure du délai total du cycle d’approbation de la demande d’achat. Où les obtenir Déduit du changement du champ de statut du document dans la table POR_REQUISITION_HEADERS_ALL, qui passe à « APPROVED ». La date de ce changement de statut correspond à l’heure de l’événement. Collecte Identifiez l’horodatage auquel le statut du document est défini pour la première fois sur « Approved ». Type d’événement inferred
	Demande d’achat clôturée	Indique la clôture définitive du cycle de vie d’une demande d’achat, lorsque toutes ses lignes ont été traitées, par exemple converties en bons de commande, ou annulées. Cet événement est déduit d’une mise à jour finale du statut.
Pourquoi c’est important Il s’agit du principal événement de fin réussie du processus. Il confirme que la demande d’achat a été entièrement traitée et qu’aucune action supplémentaire n’est requise. Où les obtenir Déduit du changement du statut de l’en-tête de la demande d’achat dans POR_REQUISITION_HEADERS_ALL, qui passe à « CLOSED ». Collecte Identifiez l’horodatage auquel le statut du document de la demande d’achat passe à « Closed ». Type d’événement inferred
	Demande d’achat rejetée	Représente le rejet final de la demande d’achat, qui met fin au processus pour cette demande. Cet événement est déduit lorsque le statut global de la demande d’achat est mis à jour sur « Rejected ».
Pourquoi c’est important Cette activité constitue le point terminal des demandes qui n’aboutissent pas. L’analyse de ces cas est essentielle pour comprendre le KPI de taux de rejet des demandes d’achat et les raisons des échecs. Où les obtenir Déduit du changement du statut du document dans la table POR_REQUISITION_HEADERS_ALL, qui passe à « REJECTED ». Collecte Identifiez l’horodatage auquel le statut du document est défini pour la première fois sur « Rejected ». Type d’événement inferred
	Demande soumise	Représente l’action de l’utilisateur qui soumet la demande dûment remplie dans le flux de travail d’approbation. Cet événement est enregistré lorsque le statut de la demande passe de « Incomplete » ou « Draft » à un statut indiquant qu’elle est en attente d’approbation.
Pourquoi c’est important Cette activité déclenche le cycle d’approbation. Il s’agit d’une étape essentielle pour mesurer le délai d’approbation de la demande d’achat et les délais globaux. Où les obtenir Déduit d’un changement de statut dans la table POR_REQUISITION_HEADERS_ALL, par exemple lorsque le statut passe à « PENDING APPROVAL ». La date de soumission est également souvent enregistrée explicitement. Collecte Identifiez l’horodatage auquel le champ de statut du document passe pour la première fois à « Pending Approval ». Type d’événement inferred
	Demande d’achat modifiée	Cet événement indique qu’un utilisateur a modifié une demande d’achat après sa soumission initiale, ce qui nécessite souvent de relancer le processus d’approbation. Il est déduit de la détection de modifications apportées à des champs de données clés ou de la création d’une nouvelle version de la demande d’achat.
Pourquoi c’est important Des modifications fréquentes indiquent des problèmes de qualité des données ou une évolution des besoins, ce qui entraîne des reprises et des retards dans le processus. Cet indicateur alimente directement le KPI « Taux de modification des demandes d’achat ». Où les obtenir Déduit du suivi des numéros de version de la demande d’achat ou de l’identification de changements de statut revenant à « Incomplete » après la soumission. Les journaux de modifications ou les tables de piste d’audit peuvent également enregistrer ces modifications. Collecte Identifiez les horodatages de création des nouvelles versions pour le même identifiant de demande d’achat après sa soumission. Type d’événement inferred
	Demande d’achat retirée	Se produit lorsque le demandeur annule ou retire une demande d’achat soumise avant son approbation complète. Il s’agit généralement d’une action explicite de l’utilisateur qui entraîne un changement de statut.
Pourquoi c’est important Le suivi des retraits permet d’identifier les raisons d’une interruption prématurée, comme l’évolution des besoins de l’entreprise ou la correction d’erreurs par les utilisateurs après la soumission. Où les obtenir Déduit d’un changement de statut vers « WITHDRAWN » dans la table POR_REQUISITION_HEADERS_ALL. L’action est enregistrée dans l’historique des actions de la demande d’achat. Collecte Détectez l’horodatage auquel le statut de la demande d’achat est mis à jour sur « Withdrawn ». Type d’événement inferred
	Étape d’approbation approuvée	Représente l’action d’un approbateur qui approuve la demande à l’étape qui lui est attribuée dans le flux de travail. L’événement est enregistré explicitement dans l’historique des approbations.
Pourquoi c’est important Le suivi des différentes étapes d’approbation permet de cartographier le parcours d’approbation réel et de mesurer le temps de traitement à chaque niveau de la hiérarchie. Où les obtenir Extrait de l’historique des actions d’approbation de la demande, généralement stocké dans les tables du flux de travail (WF) ou de Human Capital Management (HCM) qui gèrent les hiérarchies d’approbation. Collecte Utilisez l’horodatage de l’action « APPROVE » dans le journal de l’historique des actions du flux de travail. Type d’événement explicit
	Étape d’approbation démarrée	Marque le moment où une demande est attribuée à un approbateur ou à un groupe d’approbation précis dans le flux de travail. L’information est extraite du journal des transactions du moteur de flux de travail.
Pourquoi c’est important Cette activité est essentielle pour calculer le temps d’attente de chaque étape d’approbation. Elle aide à localiser les goulots d’étranglement liés à certains approbateurs ou niveaux d’approbation. Où les obtenir Extrait des tables de flux de travail d’Oracle Fusion, qui enregistrent les tâches attribuées aux utilisateurs. L’horodatage d’attribution de la tâche d’approbation est utilisé. Collecte Utilisez l’horodatage de création de la tâche dans l’historique du flux de travail pour la demande concernée. Type d’événement explicit
	Étape d’approbation rejetée	Un approbateur rejette la demande, ce qui la renvoie généralement au préparateur pour correction ou met fin à la demande. Cette action est enregistrée explicitement dans l’historique du flux de travail.
Pourquoi c’est important Cette activité est une cause majeure de reprises et de retards. L’analyse des rejets aide à identifier les problèmes de conformité, les difficultés budgétaires ou les justifications peu claires. Où les obtenir Extrait de l’historique des actions d’approbation de la demande. Le système de flux de travail enregistre une action « REJECT » avec son horodatage. Collecte Utilisez l’horodatage de l’action « REJECT » dans le journal de l’historique des actions du flux de travail. Type d’événement explicit
	Étape d’approbation renvoyée	Un approbateur renvoie la demande au préparateur pour obtenir des informations complémentaires ou apporter des corrections mineures, sans la rejeter officiellement. Il s’agit généralement d’une action explicite dans le système de flux de travail.
Pourquoi c’est important Cela indique qu’une clarification est nécessaire et crée une boucle de reprise qui allonge le délai du cycle. Distinguer les renvois des rejets permet de mieux comprendre les points de friction du processus. Où les obtenir Extrait de l’historique des actions d’approbation de la demande. Le système de flux de travail enregistre une action « RETURN » ou une action similaire avec son horodatage. Collecte Utilisez l’horodatage de l’action « RETURN » ou « Request for Information » dans l’historique du flux de travail. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis Oracle Fusion Financials

Étapes

Accédez à Reports and Analytics : Connectez-vous à Oracle Fusion Financials. Dans le menu Navigator, accédez à Tools, puis sélectionnez Reports and Analytics. Il s’agit du point central pour toutes les activités de reporting.
Créez une nouvelle analyse : Dans l’espace de travail Reports and Analytics, cliquez sur le bouton « Create », puis sélectionnez « Analysis » dans le menu déroulant. L’éditeur d’analyse Oracle Transactional Business Intelligence (OTBI) s’ouvre dans un nouvel onglet.
Sélectionnez le Subject Area : Vous serez invité à sélectionner un Subject Area. Dans le champ de recherche, saisissez « Procurement - Requisitions Real Time », puis sélectionnez-le dans la liste. Ce Subject Area contient toutes les données nécessaires sur les événements du cycle de vie des demandes d’achat.
Créez l’analyse des événements de demande d’achat : Cette étape consiste à réunir plusieurs requêtes afin de capturer chaque événement distinct. Comme l’interface OTBI ne propose pas directement de fonction UNION ALL pour différents types d’événements, vous devez créer un rapport unique regroupant tous les champs de date et de statut pertinents. Dans l’onglet « Criteria », faites glisser les colonnes indiquées dans la section de requête depuis le volet « Subject Areas » vers la zone « Selected Columns ». Cela inclut notamment les colonnes relatives à la date de création, à la date de soumission, à la date d’approbation et à la date de création du bon de commande.
Ajoutez l’historique des actions de la demande d’achat : Pour capturer les étapes d’approbation détaillées, notamment Approved, Rejected, Returned et Withdrawn, vous devez inclure les champs du dossier « Requisition Action History » dans le Subject Area. Faites glisser « Action Date », « Action » et « Performer » dans les colonnes sélectionnées.
Configurez les filtres : Accédez à l’onglet « Prompts » pour créer les filtres de votre analyse. Il est essentiel de filtrer selon une période afin de maîtriser le volume de données. Créez un filtre sur « Requisition Header ».« Requisition Creation Date » et définissez une période, par exemple les six derniers mois. Vous pouvez également ajouter des invites pour « Business Unit » ou « Requester Name » afin de restreindre les données.
Exécutez et vérifiez le rapport : Accédez à l’onglet « Results » pour exécuter l’analyse et prévisualiser les données. Le résultat se présente sous la forme d’un tableau « large », avec une ligne par ligne de demande d’achat ou par action d’approbation, et plusieurs colonnes de dates et de statuts.
Exportez les données brutes : Lorsque l’aperçu vous convient, cliquez sur le lien « Export », généralement situé en bas de la page de résultats. Sélectionnez « Data » > « CSV File » comme format. Les données brutes de votre analyse seront téléchargées.
Transformez les données au format Event Log : Le fichier CSV exporté est au format large. Vous devez utiliser un outil externe, comme un script Python, Power Query dans Excel ou un autre outil de préparation des données, pour le transformer. Cette opération consiste à convertir les colonnes de dates en une seule colonne « EventTime » et à créer une colonne « ActivityName » correspondante pour chaque type d’événement, par exemple « Requisition Created » et « Requisition Submitted ».
Finalisez le fichier et préparez son importation : Après la transformation, vérifiez que le fichier contient les colonnes requises : PurchaseRequisitionId, ActivityName, EventTime, SourceSystem et LastDataUpdate. Enregistrez l’Event Log final au format CSV afin de pouvoir l’importer dans ProcessMind.

Configuration

Subject Area : Le Subject Area principal à utiliser est « Procurement - Requisitions Real Time ». Il contient les informations essentielles sur les en-têtes et lignes de demandes d’achat, les distributions et l’historique des approbations.
Période : Appliquez toujours un filtre de date obligatoire afin de limiter le volume de données et d’améliorer les performances. Un filtre sur « Requisition Header ».« Requisition Creation Date » couvrant les trois à six derniers mois constitue un bon point de départ.
Filtres principaux : Envisagez d’ajouter des filtres sur « Requisition Header ».« Business Unit » et « Requisition Header ».« Requisition Status » afin de limiter l’extraction aux unités organisationnelles pertinentes et d’exclure les statuts inutiles, comme « Canceled », s’ils ne sont pas nécessaires à l’analyse.
Sélection des colonnes : Sélectionnez soigneusement les colonnes ajoutées à l’analyse. L’ajout d’un trop grand nombre de colonnes, notamment depuis plusieurs dossiers ou dimensions, peut dégrader les performances. Concentrez-vous sur les champs nécessaires à l’Event Log.
Autorisations : L’utilisateur qui exécute l’extraction doit disposer d’un rôle lui permettant d’accéder à l’espace de travail Reports and Analytics et au Subject Area « Procurement - Requisitions Real Time ». Des rôles tels que « BI Author » ou « Procurement Analyst » disposent généralement de ces privilèges.

a Exemple de requête sql

/*
OTBI analyses are built visually, not with SQL. This conceptual query illustrates the logic required to extract the data for all specified activities. The user would build an analysis containing these fields and then transform the output into an event log.
*/

-- 1. Requisition Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Created' AS ActivityName,
  "Requisition Header"."Requisition Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Creation Date" IS NOT NULL

UNION ALL

-- 2. Requisition Submitted
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Submitted' AS ActivityName,
  "Requisition Header"."Submitted Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Submitted Date" IS NOT NULL

UNION ALL

-- 3, 5, 6, 7, 8. Approval History Events (Withdrawn, Started, Approved, Rejected, Returned)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  CASE "Requisition Action History"."Action"
    WHEN 'WITHDRAW' THEN 'Requisition Withdrawn'
    WHEN 'SUBMIT' THEN 'Approval Step Started' -- Assumes submit action assigns to first approver
    WHEN 'APPROVE' THEN 'Approval Step Approved'
    WHEN 'REJECT' THEN 'Approval Step Rejected'
    WHEN 'RETURN' THEN 'Approval Step Returned'
  END AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  CASE WHEN "Requisition Action History"."Action" = 'REJECT' THEN "Requisition Action History"."Action Note" ELSE NULL END AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Action History"."Action" IN ('WITHDRAW', 'SUBMIT', 'APPROVE', 'REJECT', 'RETURN')

UNION ALL

-- 4. Requisition Amended
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Amended' AS ActivityName,
  "Requisition Header"."Last Update Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Version" > 1 AND "Requisition Header"."Last Update Date" > "Requisition Header"."Submitted Date"

UNION ALL

-- 9. Requisition Approved (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Approved' AS ActivityName,
  "Requisition Header"."Approved Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'APPROVED'
AND "Requisition Header"."Approved Date" IS NOT NULL

UNION ALL

-- 10. Requisition Rejected (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Rejected' AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  "Requisition Action History"."Action Note" AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'REJECTED'
AND "Requisition Action History"."Action" = 'REJECT'
AND "Requisition Action History"."Sequence Number" = (SELECT MAX(T2."Sequence Number") FROM "Procurement - Requisitions Real Time" T2 WHERE T2."Requisition Header"."Requisition Number" = "Requisition Header"."Requisition Number")

UNION ALL

-- 11. Purchase Order Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Purchase Order Created' AS ActivityName,
  "Purchase Order Schedule"."PO Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Purchase Order Schedule"."PO Creation Date" IS NOT NULL

UNION ALL

-- 12. Requisition Closed
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Closed' AS ActivityName,
  "Requisition Line"."Line Close Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Line"."Line Close Date" IS NOT NULL AND "Requisition Line"."Line Status" = 'CLOSED'

Étapes

Connectez-vous à Oracle Fusion Financials avec un utilisateur disposant du rôle BI Author ou de privilèges équivalents.
Accédez à l’espace de travail Reports and Analytics en cliquant sur l’icône Navigator, puis en sélectionnant Tools > Reports and Analytics.
Cliquez sur le bouton « Browse Catalog » pour ouvrir le catalogue Business Intelligence Publisher.
Dans l’interface BI Publisher, cliquez sur « New », puis sélectionnez « Data Model » dans la liste déroulante.
Dans les propriétés du Data Model, vous pouvez saisir un nom et une description. Cliquez sur l’icône « + » pour ajouter un Data Set, puis sélectionnez « SQL Query ».
Dans la boîte de dialogue du nouveau Data Set, saisissez un nom, par exemple Requisition_Event_Log, sélectionnez la Data Source appropriée pour vos données Financials, par exemple ApplicationDB_FSCM, et définissez le type SQL sur « Standard SQL ».
Copiez l’intégralité du script SQL fourni dans la section « query » de ce document et collez-le dans la zone de texte SQL Query.
La requête contient les paramètres :p_start_date et :p_end_date. BI Publisher les reconnaît automatiquement. Vous pouvez définir des valeurs par défaut si nécessaire.
Enregistrez le Data Model dans un dossier approprié du catalogue, par exemple Shared Folders/Custom.
Pour exporter les données, retournez au catalogue, cliquez sur « New », puis sélectionnez « Report ». Associez ce nouveau rapport au Data Model que vous venez de créer.
Exécutez le rapport en indiquant les paramètres de date de début et de fin. Lorsque les données s’affichent, utilisez la fonction « Export » pour télécharger les résultats au format CSV.
Vérifiez que le fichier CSV final est enregistré avec l’encodage UTF-8 et contient les en-têtes requis pour son ingestion dans votre outil de Process Mining.

Configuration

Source de données : La source de données BI Publisher, généralement nommée ’ApplicationDB_FSCM’ ou équivalent, doit être configurée avec un utilisateur disposant d’un accès en lecture à toutes les tables utilisées dans la requête, notamment celles de Procurement (POR, PO), de Human Capital Management (PER, HR) et de Financials (FUN).
Filtrage par période : La requête utilise les paramètres de date obligatoires (:p_start_date et :p_end_date), qui filtrent les données selon la date de création de la demande d’achat. Pour les premières extractions ou les systèmes volumineux, il est essentiel d’extraire les données par lots gérables, par exemple trois à six mois à la fois, afin d’éviter les dépassements de délai du système.
Filtrage par unité opérationnelle : Un filtre sur le nom de l’unité opérationnelle figure dans une section commentée de la clause WHERE de la requête. Il est vivement recommandé de décommenter et de configurer ce filtre afin de limiter les données aux unités opérationnelles pertinentes pour votre analyse, ce qui peut améliorer considérablement les performances.
Prérequis : L’utilisateur qui crée et exécute le rapport doit disposer d’un rôle lui accordant les privilèges BI Publisher, tel que ’BI Administrator Role’ ou ’BI Author Role’. Cet utilisateur doit également bénéficier des autorisations de sécurité nécessaires pour accéder aux données d’approvisionnement.

a Exemple de requête sql

WITH BaseRequisitions AS (
    SELECT
        PRH.REQUISITION_HEADER_ID,
        PRH.REQUISITION_NUMBER,
        PRH.CREATION_DATE,
        PRH.LAST_UPDATE_DATE AS HEADER_LAST_UPDATE_DATE,
        PRH.DOCUMENT_STATUS,
        PRH.PREPARER_ID,
        PPNF_REQ.DISPLAY_NAME AS RequesterName,
        HOU.NAME AS DepartmentName,
        BU.BU_NAME AS BusinessUnit,
        SUM(PRL.AMOUNT) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequisitionTotalAmount,
        MIN(PRL.NEED_BY_DATE) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequiredByDate
    FROM
        POR_REQUISITION_HEADERS_ALL PRH
    JOIN
        POR_REQUISITION_LINES_ALL PRL ON PRH.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
    JOIN
        PER_USERS PU_REQ ON PRH.PREPARER_ID = PU_REQ.USER_ID
    LEFT JOIN
        PER_PERSON_NAMES_F PPNF_REQ ON PU_REQ.PERSON_ID = PPNF_REQ.PERSON_ID AND PPNF_REQ.NAME_TYPE = 'GLOBAL' AND SYSDATE BETWEEN PPNF_REQ.EFFECTIVE_START_DATE AND PPNF_REQ.EFFECTIVE_END_DATE
    LEFT JOIN
        PER_ALL_ASSIGNMENTS_F PAAF ON PU_REQ.PERSON_ID = PAAF.PERSON_ID AND PAAF.ASSIGNMENT_TYPE = 'E' AND PAAF.PRIMARY_FLAG = 'Y' AND SYSDATE BETWEEN PAAF.EFFECTIVE_START_DATE AND PAAF.EFFECTIVE_END_DATE
    LEFT JOIN
        HR_ORGANIZATION_UNITS_F_VL HOU ON PAAF.ORGANIZATION_ID = HOU.ORGANIZATION_ID AND SYSDATE BETWEEN HOU.EFFECTIVE_START_DATE AND HOU.EFFECTIVE_END_DATE
    JOIN
        FUN_ALL_BUSINESS_UNITS_V BU ON PRH.REQ_BU_ID = BU.BU_ID
    WHERE PRH.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
    -- AND BU.BU_NAME IN ('[Your Business Unit Name]') -- Recommended: Uncomment and specify your Business Unit(s)
)
-- 1. Requisition Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Created' AS "ActivityName",
    BR.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR

UNION ALL

-- 2. Requisition Submitted, 4. Requisition Amended
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    CASE 
        WHEN PAH.OBJECT_REVISION_NUM > 1 THEN 'Requisition Amended'
        ELSE 'Requisition Submitted'
    END AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'SUBMIT'

UNION ALL

-- 3. Requisition Withdrawn
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Withdrawn' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'WITHDRAW'

UNION ALL

-- 5. Approval Step Started
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Started' AS "ActivityName",
    PAH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE IN ('APPROVE', 'REJECT', 'SUBMIT', 'RETURN')

UNION ALL

-- 6. Approval Step Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'APPROVE'

UNION ALL

-- 7. Approval Step Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'

UNION ALL

-- 8. Approval Step Returned
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Returned' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'RETURN'

UNION ALL

-- 9. Requisition Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'APPROVED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'FINALLY CLOSE' AND BR.DOCUMENT_STATUS = 'APPROVED'

UNION ALL

-- 10. Requisition Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'REJECTED' AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'
AND BR.DOCUMENT_STATUS = 'REJECTED'
AND PAH.ACTION_DATE = (SELECT MAX(PAH2.ACTION_DATE) FROM PO_ACTION_HISTORY PAH2 WHERE PAH2.OBJECT_ID = BR.REQUISITION_HEADER_ID AND PAH2.ACTION_CODE = 'REJECT')

UNION ALL

-- 11. Purchase Order Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Purchase Order Created' AS "ActivityName",
    POH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN POR_REQUISITION_LINES_ALL PRL ON BR.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
JOIN PO_DISTRIBUTIONS_ALL POD ON PRL.REQUISITION_LINE_ID = POD.REQUISITION_LINE_ID
JOIN PO_HEADERS_ALL POH ON POD.PO_HEADER_ID = POH.PO_HEADER_ID

UNION ALL

-- 12. Requisition Closed
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Closed' AS "ActivityName",
    BR.HEADER_LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'CLOSED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
WHERE BR.DOCUMENT_STATUS = 'CLOSED'

Étapes

Prérequis et configuration de l’environnement : Vérifiez que Python 3 est installé sur votre système. Installez la bibliothèque requests nécessaire en exécutant la commande suivante dans votre terminal : pip install requests. Vous aurez également besoin des identifiants d’API, à savoir le nom d’utilisateur et le mot de passe, d’un utilisateur Oracle Fusion disposant des autorisations suffisantes pour lire les données des demandes d’achat, ainsi que de l’URL de base de votre instance Oracle Fusion.
Enregistrez le script Python : Enregistrez le code Python complet fourni dans la section « query » dans un fichier, par exemple extract_requisitions.py.
Configurez les paramètres du script : Ouvrez le fichier du script dans un éditeur de texte. Modifiez les valeurs fictives situées en haut du script. Définissez FUSION_URL, USERNAME et PASSWORD selon les informations de votre environnement Oracle Fusion. Ajustez START_DATE et END_DATE pour définir la période d’extraction.
Comprenez les points de terminaison et les champs de l’API : Le script cible la ressource d’API REST purchaseRequisitions. Il utilise le paramètre fields pour demander uniquement les données nécessaires, notamment les collections imbriquées comme lines, pour les informations de bon de commande, et actionHistory, pour les événements d’approbation, ce qui améliore les performances.
Exécutez le script : Lancez le script depuis votre terminal à l’aide de la commande suivante : python extract_requisitions.py. Le script s’authentifie auprès de l’API, commence à récupérer les données et affiche l’avancement dans la console, notamment le nombre de demandes d’achat traitées.
Gérez la pagination : Le script gère automatiquement la pagination. L’API REST Oracle Fusion renvoie les données par blocs, ou pages. Le script vérifie l’indicateur hasMore dans chaque réponse et envoie de nouvelles requêtes avec un paramètre offset mis à jour jusqu’à la récupération de toutes les demandes d’achat comprises dans la période indiquée.
Logique de transformation des données : Pour chaque demande d’achat récupérée depuis l’API, le script génère plusieurs lignes dans l’Event Log. Il crée un événement « Requisition Created » à partir de CreationDate, un événement « Requisition Submitted » à partir de SubmittedDate, puis parcourt la collection actionHistory pour créer les événements détaillés de chaque étape d’approbation, notamment Started, Approved, Rejected et Returned.
Déduisez les événements de statut final : Le script capture les événements de résultat final, comme « Requisition Approved » et « Requisition Rejected », en vérifiant la valeur finale de DocumentStatus et en utilisant LastUpdateDate comme horodatage de l’événement.
Générez l’événement de bon de commande : Le script examine chaque ligne de demande d’achat. Si une ligne contient un PoHeaderId, cela signifie qu’un bon de commande a été créé. Une entrée est alors générée dans l’Event Log pour cette activité, en reliant la demande d’achat au processus d’achat en aval.
Vérifiez le fichier de sortie : À la fin de l’exécution du script, un fichier CSV nommé oracle_fusion_requisitions_event_log.csv est créé dans le même répertoire. Il contient l’Event Log extrait.
Préparez l’importation : Ouvrez le fichier CSV généré dans un tableur afin d’en vérifier le contenu. Assurez-vous que les colonnes et les formats de données correspondent aux exigences de votre outil de Process Mining. Le fichier est désormais prêt à être importé dans ProcessMind.

Configuration

Identifiants d’API : Un compte utilisateur d’intégration dédié, associé à un rôle accordant un accès en lecture seule à l’API REST Purchase Requisitions, est requis. Parmi les rôles possibles figurent Procurement Manager ou un rôle d’intégration personnalisé.
Point de terminaison de l’API REST : Le script utilise le point de terminaison .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Vérifiez que le numéro de version de l’URL correspond à votre environnement Oracle Fusion.
Filtre de période : Le script contient les variables START_DATE et END_DATE. Il est vivement recommandé d’extraire les données par lots maîtrisables, par exemple trois à six mois à la fois, afin d’éviter les dépassements de délai de l’API et les problèmes de performance. Le filtre s’applique à la CreationDate des demandes d’achat.
Sélection des champs : Le paramètre fields du script est essentiel aux performances. Il limite la réponse aux seuls attributs nécessaires à l’Event Log, ce qui réduit le trafic réseau et le temps de traitement. Ne supprimez pas les champs requis tels que RequisitionId, CreationDate, actionHistory ou lines.
Limite de pagination : Le paramètre limit est défini sur 100, une valeur adaptée à la plupart des environnements. Vous pouvez essayer de l’augmenter à 200 ou 500 pour accélérer potentiellement l’extraction, mais tenez compte des problèmes de mémoire ou des limites de l’API si cette valeur est trop élevée.

a Exemple de requête python

import requests
import csv
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password.
FUSION_URL = class="hl-string">"https://[your-fusion-instance-url].oraclecloud.com"
USERNAME = class="hl-string">"your_api_user"
PASSWORD = class="hl-string">"your_api_password"

class=class="hl-string">"hl-comment"># Define the date range for the extraction.
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_requisitions_data():
    class="hl-string">"""Fetches and processes purchase requisition data from Oracle Fusion REST API."""
    
    api_url = fclass="hl-string">"{FUSION_URL}/fscmRestApi/resources/11.13.18.05/purchaseRequisitions"
    
    class=class="hl-string">"hl-comment"># Define the fields to retrieve to optimize the API call
    fields_to_get = [
        class="hl-string">"RequisitionId", class="hl-string">"RequisitionNumber", class="hl-string">"CreationDate", class="hl-string">"SubmittedDate", class="hl-string">"LastUpdateDate",
        class="hl-string">"DocumentStatus", class="hl-string">"PreparerName", class="hl-string">"BusinessUnitName", class="hl-string">"RequisitionTotal", class="hl-string">"NeedByDate",
        class="hl-string">"Department", class="hl-string">"RejectionReason", 
        class="hl-string">"actionHistory(ActionCode,ActionDate,PerformerName)",
        class="hl-string">"lines(PoHeaderId,LastUpdateDate)"
    ]
    
    class=class="hl-string">"hl-comment"># Parameters for the API request
    params = {
        class="hl-string">"q": fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">"fields": class="hl-string">",".join(fields_to_get),
        class="hl-string">"limit": 100,
        class="hl-string">"offset": 0
    }
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourceitem+json'
    }
    
    event_log = []
    has_more = True
    total_processed = 0
    now_iso = datetime.utcnow().isoformat() + class="hl-string">'Z'

    while has_more:
        print(fclass="hl-string">"Fetching requisitions from offset {params['offset']}...")
        try:
            response = requests.get(
                api_url, 
                auth=(USERNAME, PASSWORD), 
                params=params, 
                headers=headers
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes (4xx or 5xx)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break

        data = response.json()
        requisitions = data.get(class="hl-string">'items', [])

        if not requisitions:
            print(class="hl-string">"No more requisitions found.")
            break

        for req in requisitions:
            base_event = {
                class="hl-string">'PurchaseRequisitionId': req.get(class="hl-string">'RequisitionNumber'),
                class="hl-string">'RequesterName': req.get(class="hl-string">'PreparerName'),
                class="hl-string">'DepartmentName': req.get(class="hl-string">'Department'),
                class="hl-string">'RequisitionTotalAmount': req.get(class="hl-string">'RequisitionTotal'),
                class="hl-string">'RequisitionStatus': req.get(class="hl-string">'DocumentStatus'),
                class="hl-string">'RequiredByDate': req.get(class="hl-string">'NeedByDate'),
                class="hl-string">'RejectionReason': req.get(class="hl-string">'RejectionReason'),
                class="hl-string">'BusinessUnit': req.get(class="hl-string">'BusinessUnitName'),
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': now_iso
            }

            class=class="hl-string">"hl-comment"># 1. Requisition Created
            if req.get(class="hl-string">'CreationDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Created', class="hl-string">'EventTime': req[class="hl-string">'CreationDate']})

            class=class="hl-string">"hl-comment"># 2. Requisition Submitted
            if req.get(class="hl-string">'SubmittedDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Submitted', class="hl-string">'EventTime': req[class="hl-string">'SubmittedDate']})

            class=class="hl-string">"hl-comment"># 3-8. Approval Workflow Events from actionHistory
            po_created = False
            if class="hl-string">'actionHistory' in req and req[class="hl-string">'actionHistory'] is not None:
                for action in req[class="hl-string">'actionHistory']:
                    activity = None
                    action_code = action.get(class="hl-string">'ActionCode')
                    if action_code == class="hl-string">'SUBMIT':
                        class=class="hl-string">"hl-comment"># This is often the first step in the approval flow
                        activity = class="hl-string">'Approval Step Started'
                    elif action_code == class="hl-string">'APPROVE':
                        activity = class="hl-string">'Approval Step Approved'
                    elif action_code == class="hl-string">'REJECT':
                        activity = class="hl-string">'Approval Step Rejected'
                    elif action_code == class="hl-string">'RETURN':
                        activity = class="hl-string">'Approval Step Returned'
                    elif action_code == class="hl-string">'WITHDRAW':
                        activity = class="hl-string">'Requisition Withdrawn'
                    elif action_code == class="hl-string">'UPDATE':
                        activity = class="hl-string">'Requisition Amended'
                    
                    if activity:
                        event_log.append({**base_event, class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': action.get(class="hl-string">'ActionDate')})

            class=class="hl-string">"hl-comment"># 9-10 & 12. Final Status Events
            final_status = req.get(class="hl-string">'DocumentStatus')
            last_update_date = req.get(class="hl-string">'LastUpdateDate')
            if last_update_date:
                if final_status == class="hl-string">'APPROVED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Approved', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'REJECTED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Rejected', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'CLOSED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Closed', class="hl-string">'EventTime': last_update_date})

            class=class="hl-string">"hl-comment"># 11. Purchase Order Created
            if class="hl-string">'lines' in req and req[class="hl-string">'lines'] is not None:
                for line in req[class="hl-string">'lines']:
                    if line.get(class="hl-string">'PoHeaderId') and not po_created:
                        event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created', class="hl-string">'EventTime': line.get(class="hl-string">'LastUpdateDate', last_update_date)})
                        po_created = True class=class="hl-string">"hl-comment"># Create only one PO event per requisition
                        break
        
        total_processed += len(requisitions)
        print(fclass="hl-string">"Processed {total_processed} total requisitions so far.")

        class=class="hl-string">"hl-comment"># Check if there is more data to fetch for pagination
        has_more = data.get(class="hl-string">'hasMore', False)
        if has_more:
            params[class="hl-string">'offset'] += params[class="hl-string">'limit']

    class=class="hl-string">"hl-comment"># Write to CSV
    if event_log:
        filename = class="hl-string">'oracle_fusion_requisitions_event_log.csv'
        fieldnames = list(event_log[0].keys())
        with open(filename, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
            writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
            writer.writeheader()
            writer.writerows(event_log)
        print(fclass="hl-string">"\nSuccessfully extracted {len(event_log)} events to {filename}")
    else:
        print(class="hl-string">"\nNo events were generated.")

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

Étapes

Vérifiez que Oracle BI Cloud Connector, le contenu requis d’approvisionnement Oracle Fusion Financials et l’accès aux Public View Objects pertinents sont disponibles dans votre environnement. Vérifiez que l’utilisateur BICC ou le compte d’intégration est autorisé à extraire les données relatives aux demandes d’achat, à l’historique des approbations et aux commandes d’achat. Les noms exacts des rôles et des éléments de navigation varient selon la version d’Oracle. Utilisez donc la zone d’administration BICC correspondante dans votre tenant.
Identifiez et activez les PVO nécessaires à l’extraction. Utilisez RequisitionHeaderPVO, ou le PVO d’en-tête de demande d’achat correspondant dans votre environnement, ainsi que les PVO qui exposent les lignes de demande, l’historique des statuts de demande, l’historique du flux de travail d’approbation et les références de commande d’achat. Ne supposez pas qu’un seul PVO contient l’historique du flux de travail ou celui de la création des commandes d’achat. Consignez les noms exacts des PVO et les attributs disponibles dans votre tenant.
Configurez une tâche BICC pour une extraction groupée incrémentielle ou historique. Définissez la période d’extraction à l’aide de [Paramètre de date de début] et [Paramètre de date de fin], puis configurez la tâche pour qu’elle dépose les fichiers CSV dans l’emplacement de stockage cloud approuvé. Pour le chargement initial, utilisez une période historique suffisamment large. Pour les chargements récurrents, utilisez des périodes qui se chevauchent afin de tenir compte des mises à jour tardives, puis dédupliquez les événements à l’aide de l’identifiant du cas, de l’activité, de l’horodatage de l’événement et de l’identifiant de l’événement source lorsqu’il est disponible.
Configurez les colonnes de l’extraction. Incluez l’identifiant de la demande d’achat, les identifiants de l’en-tête et des lignes de demande, le demandeur, le service, le montant, le statut, la date requise, l’unité opérationnelle, le motif du rejet, les horodatages de création et de mise à jour, les horodatages des changements de statut, les horodatages d’affectation et d’action d’approbation, l’action d’approbation, la référence de commande d’achat et l’horodatage d’actualisation BICC. Utilisez les noms exacts des attributs exposés par les PVO sélectionnés. Si un attribut n’est pas disponible, associez-le à [À configurer selon votre système] et documentez cette limite au lieu de le remplacer par un champ non vérifié.
Extrayez les fichiers CSV sources et conservez les fichiers d’origine. Chargez chaque fichier dans une zone de préparation, conservez le nom du PVO source et le nom du fichier, normalisez les horodatages selon un fuseau horaire convenu et interprétez les valeurs de date et d’horodatage Oracle de manière cohérente. Traitez les identifiants comme des chaînes afin d’éviter la perte des zéros initiaux ou de la précision.
Restructurez les données sources en table d’événements, avec une ligne par événement métier explicite. Le résultat doit contenir PurchaseRequisitionId, ActivityName, EventTime, SourceSystem et LastDataUpdate. Ajoutez les attributs recommandés lorsqu’ils sont disponibles. Ne comptez pas sur ProcessMind pour déduire les événements à partir des statuts ou des changements de champs. La transformation doit créer explicitement des lignes pour les douze activités répertoriées dans la requête.
Construisez les lignes d’événements à partir des éléments sources appropriés. Utilisez la preuve de création de l’enregistrement pour Requisition Created, une transition explicite de soumission pour Requisition Submitted, une action ou transition explicite de retrait pour Requisition Withdrawn, une modification détectée après soumission ou une nouvelle version pour Requisition Amended, l’affectation dans le flux de travail pour Approval Step Started et les actions explicites de l’historique des approbations pour Approval Step Approved, Approval Step Rejected et Approval Step Returned. Utilisez une transition explicite du statut global pour Requisition Approved, Requisition Rejected et Requisition Closed. Utilisez un enregistrement explicite de création de commande d’achat ou un horodatage de création associé à la demande pour Purchase Order Created.
Appliquez une déduplication déterministe. Si plusieurs lignes sources représentent le même événement, conservez une seule ligne en utilisant l’horodatage d’événement le plus précis et un identifiant source stable lorsqu’il est disponible. Ne regroupez pas des étapes d’approbation distinctes au seul motif qu’elles partagent le même identifiant de demande. Conservez des événements d’approbation distincts pour les différents approbateurs ou étapes du flux de travail.
Validez le journal d’événements obtenu. Vérifiez que chaque activité requise est représentée, que chaque événement possède un identifiant de cas et un horodatage, que les horodatages se situent dans la période d’extraction ou que les mises à jour tardives sont expliquées, et que les attributs recommandés sont renseignés lorsque la source les fournit. Rapprochez les volumes de demandes d’achat et les liens vers les commandes d’achat avec les extractions sources.
Exportez le journal d’événements final au format CSV UTF-8, avec une ligne d’en-tête et un événement par ligne. Utilisez exactement les noms de colonnes PurchaseRequisitionId, ActivityName, EventTime, SourceSystem et LastDataUpdate, ainsi que les attributs recommandés. Importez le fichier CSV dans ProcessMind et configurez PurchaseRequisitionId comme identifiant du cas, ActivityName comme activité et EventTime comme horodatage de l’événement.

Configuration

Méthode d’extraction : extraction groupée de données avec Oracle BI Cloud Connector, fournie sous forme de fichiers CSV dans l’emplacement de stockage cloud configuré.
Objets sources : utilisez RequisitionHeaderPVO ainsi que les PVO correspondants disponibles dans le tenant pour les lignes de demande, l’historique des statuts, l’historique du flux de travail d’approbation et les références de commande d’achat. Les noms exacts des PVO et des attributs doivent être confirmés dans l’environnement.
Colonnes de sortie obligatoires : PurchaseRequisitionId, ActivityName, EventTime, SourceSystem et LastDataUpdate.
Colonnes de sortie recommandées : RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason et BusinessUnit.
Période : utilisez trois à six mois pour l’analyse courante. Pour un premier chargement historique, utilisez une période plus large si nécessaire. Pour les extractions récurrentes, utilisez des périodes qui se chevauchent afin de capturer les mises à jour tardives, puis dédupliquez les données.
Filtres : appliquez [Filtre propre à l’entreprise], [Filtre de type de document], [Filtre d’unité opérationnelle] et [Filtre de période] uniquement lorsque ces attributs sont disponibles dans les PVO sélectionnés. Vérifiez si le filtre s’applique à la date de création, à la date de mise à jour, à la date de changement de statut ou à une autre date source.
Extraction incrémentielle : privilégiez un horodatage de mise à jour ou un mécanisme d’extraction incrémentielle pris en charge et exposé par BICC. Conservez le point de reprise de la dernière extraction réussie et prévoyez un léger chevauchement lors de l’exécution suivante.
Exhaustivité des événements : configurez des extractions sources distinctes lorsque les en-têtes de demande n’exposent pas l’historique des approbations, les changements de statut, les modifications ou la création des commandes d’achat. Une extraction de l’état courant des en-têtes ne permet pas, à elle seule, de reconstituer de manière fiable les événements historiques.
Performances : limitez la période et les colonnes sélectionnées, partitionnez les extractions volumineuses lorsque cette option est disponible, évitez les attributs descriptifs inutiles et traitez les fichiers CSV par lots. Conservez les fichiers sources pour les rapprochements.
Stockage : configurez un emplacement de stockage cloud approuvé offrant une capacité, une durée de conservation, un chiffrement et des contrôles d’accès suffisants. Vérifiez que le compte d’extraction peut écrire les fichiers et que le processus de transformation peut les lire.
Prérequis : disponibilité de BICC, accès aux données d’approvisionnement et d’approbation Oracle Fusion pertinentes, autorisations d’intégration appropriées, accès aux PVO sélectionnés et tout abonnement ou droit d’utilisation Oracle requis. Les noms exacts des rôles, les licences et les chemins de navigation dépendent de la version d’Oracle et de la configuration du tenant.
Gestion du temps : normalisez tous les horodatages sources selon un fuseau horaire documenté et conservez l’horodatage d’origine lorsque la traçabilité l’exige.
Gestion des cas : utilisez PurchaseRequisitionId comme identifiant du cas. N’utilisez pas l’identifiant d’une ligne de demande comme identifiant du cas, sauf si le processus est volontairement modélisé au niveau de la ligne.

a Exemple de requête sql

WITH
source_requisition AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([Creation timestamp attribute] AS TIMESTAMP) AS CreatedAt,
        CAST([Submission timestamp attribute] AS TIMESTAMP) AS SubmittedAt,
        CAST([Withdrawal timestamp attribute] AS TIMESTAMP) AS WithdrawnAt,
        CAST([Approval timestamp attribute] AS TIMESTAMP) AS ApprovedAt,
        CAST([Rejection timestamp attribute] AS TIMESTAMP) AS RejectedAt,
        CAST([Closure timestamp attribute] AS TIMESTAMP) AS ClosedAt,
        CAST([Last update timestamp attribute] AS TIMESTAMP) AS SourceLastUpdate,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition header extract or view]
    WHERE CAST([Last update timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Last update timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
      AND ([Company filter attribute] = '[Company-specific filter]' OR '[Company-specific filter]' = '[All companies]')
      AND ([Document type filter attribute] = '[Document Type filter]' OR '[Document Type filter]' = '[All document types]')
),
source_status_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Previous status attribute] AS VARCHAR(200)) AS PreviousStatus,
        CAST([New status attribute] AS VARCHAR(200)) AS NewStatus,
        CAST([Status change timestamp attribute] AS TIMESTAMP) AS StatusChangedAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition status history extract or view]
    WHERE CAST([Status change timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Status change timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_amendments AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Amendment timestamp attribute] AS TIMESTAMP) AS AmendedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition amendment or version extract or view]
    WHERE CAST([Amendment timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Amendment timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_approval_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Approval step identifier attribute] AS VARCHAR(200)) AS ApprovalStepId,
        CAST([Approver or approval group attribute] AS VARCHAR(500)) AS ApproverName,
        CAST([Approval action attribute] AS VARCHAR(200)) AS ApprovalAction,
        CAST([Approval assignment timestamp attribute] AS TIMESTAMP) AS ApprovalStartedAt,
        CAST([Approval action timestamp attribute] AS TIMESTAMP) AS ApprovalActionAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Approval workflow history extract or view]
    WHERE COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_purchase_orders AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) AS PurchaseOrderCreatedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Purchase order reference extract or view]
    WHERE CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT PurchaseRequisitionId, 'Requisition Created' AS ActivityName, CreatedAt AS EventTime, RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason, BusinessUnit, LastDataUpdate FROM source_requisition WHERE CreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Submitted', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('pending approval', 'submitted', 'pending') AND LOWER(COALESCE(h.PreviousStatus, '')) IN ('incomplete', 'draft')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Withdrawn', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('withdrawn', 'cancelled', 'canceled')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Requisition Amended', a.AmendedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_amendments a WHERE a.AmendedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Started', a.ApprovalStartedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalStartedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Approved', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('approved', 'approve')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Rejected', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('rejected', 'reject')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Returned', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('returned', 'return', 'sent back', 'send back')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Approved', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'approved'
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Rejected', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'rejected'
    UNION ALL
    SELECT p.PurchaseRequisitionId, 'Purchase Order Created', p.PurchaseOrderCreatedAt, p.RequesterName, p.DepartmentName, p.RequisitionTotalAmount, p.RequisitionStatus, p.RequiredByDate, p.RejectionReason, p.BusinessUnit, p.LastDataUpdate FROM source_purchase_orders p WHERE p.PurchaseOrderCreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Closed', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('closed', 'finally closed', 'complete', 'completed')
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    'Oracle Fusion Financials' AS SourceSystem,
    LastDataUpdate,
    RequesterName,
    DepartmentName,
    RequisitionTotalAmount,
    RequisitionStatus,
    RequiredByDate,
    RejectionReason,
    BusinessUnit
FROM events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Prêt à commencer ?

Utilisez ce modèle pour commencer à optimiser votre processus Purchase to Pay - Requisition et obtenir de nouveaux gains d’efficacité. Préparez-vous à transformer vos opérations d’approvisionnement.

Retour au guide d’amélioration Télécharger le modèle

Accélérez de 30 % votre processus Purchase to Pay, demande d’achat

Optimisez votre processus de demande d’achat Oracle P2P et réduisez sa durée de cycle de 30 %.

Démarrer l’essai gratuit

Aucune carte bancaire requise, configuration en quelques minutes.

Votre modèle de données Purchase to Pay - Requisition

Votre modèle de données Purchase to Pay - Requisition

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités

Guides d’extraction

Export Oracle Transactional Business Intelligence (OTBI)

Étapes

Configuration

a Exemple de requête sql

Extraction d’un modèle de données SQL basé sur Oracle BI Publisher

Étapes

Configuration

a Exemple de requête sql

Script Python via l’API REST Oracle Fusion

Étapes

Configuration

a Exemple de requête python

Extraction groupée de données avec Oracle BI Cloud Connector (BICC)

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Accélérez de 30 % votre processus Purchase to Pay, demande d’achat

Votre modèle de données Purchase to Pay - Requisition

Votre modèle de données Purchase to Pay - Requisition

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités

Guides d’extraction

Export Oracle Transactional Business Intelligence (OTBI)

Étapes

Configuration

a Exemple de requête sql

Extraction d’un modèle de données SQL basé sur Oracle BI Publisher

Étapes

Configuration

a Exemple de requête sql

Script Python via l’API REST Oracle Fusion

Étapes

Configuration

a Exemple de requête python

Extraction groupée de données avec Oracle BI Cloud Connector (BICC)

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Accélérez de 30 % votre processus Purchase to Pay, demande d’achat

Nous attachons de l’importance à votre confidentialité

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités