> Amélioration continue des processus > Procure to Pay : demandes d’achat > Oracle Fusion Financials > Modèle de données

Votre modèle de données pour les demandes d’achat, de la commande au paiement

Oracle Fusion Financials

← Retour au guide d’amélioration

Attributs des demandes d’achat, de la commande au paiement(22) Activités des demandes d’achat, de la commande au paiement(12) Guides d’extraction(4)

Votre modèle de données pour les demandes d’achat, de la commande au paiement

Ce modèle vous guide dans la collecte des données essentielles à l’analyse de votre processus de demande d’achat, de la commande au paiement. Il précise les attributs à recueillir, les activités à suivre et les méthodes pratiques pour extraire ces informations d’Oracle Fusion Financials. Vous pourrez ainsi préparer efficacement votre journal d’événements pour le Process Mining.

Attributs recommandés à recueillir
Activités clés à suivre
Guide d’extraction pour Oracle Fusion Financials

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs des demandes d’achat, de la commande au paiement

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail les demandes d’achat, de la commande au paiement.

5 Obligatoire 7 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l’événement métier survenu à un moment précis du processus de demande d’achat.
Description L’activité correspond à une étape ou à un jalon distinct du cycle de vie d’une demande d’achat. Il peut s’agir, par exemple, de « Demande créée », « Étape d’approbation approuvée » ou « Bon de commande créé ». Ces activités sont déduites des changements de statut, des actions des utilisateurs ou des événements système consignés dans les journaux d’audit ou les tables de transactions du système source. Cet attribut est indispensable à la création de la carte de processus, qui représente visuellement le parcours des demandes. L’analyse de l’ordre et de la fréquence des activités permet de repérer les parcours les plus courants, les goulots d’étranglement, les boucles de reprise et les écarts par rapport à la procédure standard. Pourquoi est-ce important ? Cet attribut constitue la base de la carte de processus et permet de visualiser et d’analyser le flux de travail des demandes. Où trouver ces données Cet attribut est déduit des enregistrements de changement de statut dans des tables comme POR_REQUISITION_HEADERS_ALL, de l’historique des transactions ou des journaux d’audit du flux de travail, comme FA_FUSION_SOAINFRA.WFTASK. Exemples Demande d’achat 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é a eu lieu.
Description L’heure de l’événement indique la date et l’heure exactes auxquelles une activité donnée a eu lieu. Cet horodatage est indispensable pour remettre les événements d’un cas dans l’ordre chronologique. 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. L’analyse s’appuie sur l’heure de l’événement pour calculer toutes les mesures de durée, notamment les temps de cycle entre les activités, les temps d’attente et la durée totale d’un cas. Elle permet de repérer les goulots d’étranglement, de mesurer les résultats par rapport aux SLA et de comprendre l’évolution du processus de demande dans le temps. Pourquoi est-ce important ? Cet attribut est indispensable au calcul des KPI liés au temps, à la remise en ordre des événements et à l’analyse des performances du processus et de ses goulots d’étranglement. Où trouver ces données Cet attribut provient 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 comme 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 la 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 la référence centrale qui relie toutes les activités associées à une demande de biens ou de services. Chaque demande reçoit un identifiant unique lors de sa création, qui reste inchangé tout au long de son cycle de vie. En 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. Vous pouvez ainsi analyser le parcours complet de la demande, visualiser les cartes de processus, calculer les temps de cycle et étudier les variantes de chaque demande. Pourquoi est-ce important ? Cet attribut fondamental permet de suivre le cycle de vie d’une demande du début à la fin et sert de base à toutes les analyses par cas et au calcul des KPI. Où trouver ces données Il s’agit généralement de la clé primaire de la table d’en-tête des demandes, 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 la dernière actualisation des données depuis le 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 concerne l’ensemble du jeu de données, et non chaque événement individuellement. Les analystes s’en servent pour vérifier l’actualité des données et savoir jusqu’à quelle date les dernières transactions ont été prises en compte. Ces métadonnées sont utiles pour les rapports des Dashboards et permettent de confirmer que les analyses reposent sur des informations à jour. Pourquoi est-ce important ? Indique aux utilisateurs la date de mise à jour des données, afin que les analyses reposent sur les informations les plus récentes disponibles. Où trouver ces données Cet horodatage est généré et enregistré pendant 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 dont proviennent les données extraites.
Description Cet attribut indique l’origine des données du processus. Dans ce modèle de données, sa valeur sera toujours « Oracle Fusion Financials ». Dans les environnements qui utilisent plusieurs ERP ou des systèmes intégrés, ce champ est important pour retracer l’origine des données, résoudre les problèmes et en garantir la qualité. Il précise quel système fait référence pour les événements du processus analysé. Pourquoi est-ce important ? Cet attribut précise l’origine des données, un élément important pour leur gouvernance et l’intégration de données provenant de plusieurs systèmes. Où trouver ces données Il s’agit d’une valeur statique ajoutée lors de l’extraction et de la transformation des données pour indiquer l’origine du jeu de données. Exemples Oracle Fusion Financials
	Date requise RequiredByDate	Date à laquelle le demandeur a besoin des biens ou des services.
Description Le demandeur indique cette date comme échéance de réception des articles demandés. Elle sert de cible interne de niveau de service (SLA) pour le processus d’approvisionnement. Cet attribut est à la base du Dashboard « Respect de 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 montre dans quelle mesure le processus d’approvisionnement répond aux besoins internes et permet de repérer les retards récurrents. Pourquoi est-ce important ? Permet de mesurer les performances du processus par rapport aux échéances internes et de vérifier si l’approvisionnement répond aux besoins de l’entreprise dans les délais. Où trouver ces données Cet attribut est généralement stocké au niveau du poste de la demande, dans une table comme POR_REQUISITION_LINES_ALL, dans un champ tel que NEED_BY_DATE. Exemples 2023-11-012023-12-152024-01-31
	Montant total de la demande RequisitionTotalAmount	Valeur monétaire totale de la demande d’achat.
Description Cet attribut correspond à la somme des montants de tous les postes d’une demande d’achat. Il permet de mesurer l’importance financière de chaque demande. En Process Mining, le montant total sert à de nombreuses analyses. Vous pouvez, par exemple, filtrer les demandes de montant élevé, qui suivent souvent des circuits d’approbation différents ou font l’objet d’un examen plus approfondi. Les Dashboards peuvent aussi montrer comment des indicateurs du processus, comme le temps de cycle ou le taux de rejet, varient selon le montant de la demande. Pourquoi est-ce important ? Apporte un éclairage financier et permet de prioriser les améliorations selon la valeur des demandes, ainsi que d’étudier l’influence de cette valeur sur le déroulement du processus. Où trouver ces données Cet attribut figure dans l’en-tête de la demande, souvent dans un champ comme REQUISITION_TOTAL de POR_REQUISITION_HEADERS_ALL. Il peut aussi être calculé en additionnant les montants des postes de POR_REQUISITION_LINES_ALL. Exemples 550.0012500.7599.99
	Motif du rejet RejectionReason	Motif indiqué par un approbateur lorsqu’une demande ou une étape d’approbation est rejetée.
Description Lorsqu’une demande est rejetée, l’approbateur en indique généralement le motif, en choisissant une option dans une liste prédéfinie ou en saisissant un commentaire libre. Cet attribut consigne cette justification. Il est essentiel à l’analyse des 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 permet de repérer les problèmes récurrents, comme un codage incorrect, un dépassement de budget ou le non-respect des règles, puis d’y remédier par la formation ou des contrôles système. Pourquoi est-ce important ? Explique directement les raisons du rejet des demandes et permet de cibler les améliorations pour réduire les reprises et augmenter le taux de traitement sans intervention. Où trouver ces données Cet attribut provient des commentaires du flux de travail ou des champs de code de motif de rejet dans le journal d’audit du flux de travail, éventuellement dans les tables liées à FA_FUSION_SOAINFRA.WFTASK ou aux commentaires associés. Exemples Compte général incorrectDépassement du budget du centre de coûtsFournisseur non privilégié sélectionnéDemande en double
	Nom du demandeur RequesterName	Nom de l’employé 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. Il est généralement renseigné au début du processus, lors de la création de la demande. L’analyse des performances par demandeur est essentielle au Dashboard « Indicateurs de performance des demandeurs ». Elle permet de repérer 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 longs temps de cycle associés à leurs demandes. Elle apporte un éclairage sur la dimension humaine du processus. Pourquoi est-ce important ? Permet d’analyser les performances par demandeur, de repérer les besoins de formation et de mettre en évidence les utilisateurs ou les services les plus efficaces. Où trouver ces données Cet attribut provient des données d’en-tête de la demande. Il est souvent obtenu en reliant l’identifiant du demandeur à une table de référence des employés ou des utilisateurs. Recherchez les champs liés à PREPARER_ID dans POR_REQUISITION_HEADERS_ALL et reliez-les à PER_ALL_PEOPLE_F. Exemples Jean MartinJeanne DupontÉmilie Jones
	Service DepartmentName	Service auquel appartient le demandeur.
Description Cet attribut indique l’unité organisationnelle de la personne qui a créé la demande, par exemple les finances, l’informatique ou le marketing. Il est généralement déduit du profil du demandeur dans le système RH. L’analyse par service est une méthode courante pour segmenter les données du processus. Elle permet de repérer des comportements propres à certains services, comme un taux de rejet plus élevé ou des temps de cycle plus longs, et d’orienter les initiatives d’amélioration en conséquence. C’est une dimension importante du Dashboard « Indicateurs de performance des demandeurs ». Pourquoi est-ce important ? Permet de segmenter l’analyse par unité opérationnelle et de repérer les tendances, les performances et les problèmes de conformité propres à chaque service. Où trouver ces données Cet attribut est généralement déduit du profil du demandeur. Il faut souvent relier la table des demandes à une table RH ou à un annuaire des utilisateurs contenant les informations sur le service. Exemples Technologies de l’informationFinancesOpérationsMarketing
	Statut de la demande RequisitionStatus	Statut actuel ou final de la demande d’achat.
Description Cet attribut indique l’état général de la demande à un moment donné ou son résultat final, par exemple « Approuvé », « Rejeté », « En cours » ou « Clôturé ». Il sert souvent de source pour déduire de nombreuses activités du journal d’événements. Cet attribut est essentiel au Dashboard « Vue d’ensemble du statut des demandes », qui donne un aperçu de la charge de travail et du retard accumulé. Il sert également à calculer les KPI liés aux résultats, comme le taux de rejet des demandes, en filtrant les cas qui se terminent par un statut donné. Pourquoi est-ce important ? Donne un aperçu de l’état actuel des demandes et permet de déterminer leur résultat final pour calculer les KPI. Où trouver ces données Cet attribut figure dans la table d’en-tête de la demande, généralement dans un champ comme DOCUMENT_STATUS ou APPROVAL_STATUS de POR_REQUISITION_HEADERS_ALL. Exemples APPROUVÉEN COURSREJETÉRETIRÉ
	Unité opérationnelle BusinessUnit	Unité opérationnelle précise de l’organisation à laquelle se rattache la demande.
Description L’unité opérationnelle désigne une entité juridique ou fonctionnelle distincte de l’entreprise pour laquelle la demande est effectuée. Elle se situe à un niveau organisationnel supérieur à celui d’un service. L’analyse des données par unité opérationnelle permet de comparer les performances à l’échelle des différentes entités de l’organisation. La direction peut ainsi déterminer si les inefficacités sont localisées ou généralisées et savoir où concentrer les efforts d’amélioration. Cette dimension sert à filtrer la plupart des Dashboards et des KPI. Pourquoi est-ce important ? Apporte une vue d’ensemble de l’organisation et permet de comparer les performances et d’orienter les analyses stratégiques entre ses différentes entités. Où trouver ces données Il s’agit d’un champ organisationnel fondamental dans Oracle Fusion, généralement disponible dans l’en-tête de la demande, dans des tables comme POR_REQUISITION_HEADERS_ALL. Exemples Unité opérationnelle Amérique du NordUnité opérationnelle EuropeSiège social
	A été modifiée IsAmendedFlag	Indicateur booléen qui vaut vrai si la demande a été modifiée au moins une fois.
Description Cet attribut calculé indique si une demande a été modifiée après sa soumission initiale. Il est déterminé en recherchant une activité « Demande modifiée » dans l’historique du cas. Cet indicateur simplifie l’analyse et le calcul des KPI. Il sert directement à calculer le KPI « Taux de modification des demandes » et à repérer les cas qui n’ont pas été traités sans intervention. Il permet de filtrer facilement les demandes et de comparer les indicateurs du processus selon qu’elles ont été modifiées ou non. Pourquoi est-ce important ? Simplifie le calcul du taux de modification et facilite la comparaison entre les demandes modifiées et celles qui ne l’ont pas été. Où trouver ces données Cet attribut n’existe pas dans le système source. Il est calculé lors de la transformation des données à partir de la présence d’activités de modification dans le journal d’événements. Exemples truefalse
	A été traitée sans intervention IsStraightThrough	Indicateur précisant si la demande a été approuvée sans modification ni rejet.
Description Cet indicateur calculé repère les demandes 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 suivi le processus prévu sans intervention supplémentaire. Cet attribut sert de base au KPI « Taux de traitement des demandes sans intervention ». L’analyse des caractéristiques de ces demandes, comme les services, les demandeurs ou les types concernés, peut mettre en évidence des pratiques efficaces et des possibilités d’automatisation. À l’inverse, l’étude des autres cas aide à repérer les principales causes d’inefficacité. Pourquoi est-ce important ? Mesure directement l’efficacité du processus et sert de base au KPI « Taux de traitement des demandes sans intervention », tout en aidant à repérer les causes des reprises. Où trouver ces données Cet attribut est calculé lors de la transformation des données. Un cas est marqué comme vrai si aucune activité « Demande modifiée » ou « Étape d’approbation rejetée » n’est présente. Exemples truefalse
	Circuit d’approbation ApprovalWorkflowPath	Séquence prédéfinie des approbateurs ou des groupes d’approbation requis pour la demande.
Description Cet attribut définit le circuit d’approbation standard attendu pour une demande, selon les règles de l’entreprise et des critères comme le montant, le type ou le service concerné. Il représente le processus cible. Le circuit d’approbation est essentiel à l’analyse de la conformité. Il alimente directement le Dashboard « Analyse de la conformité et des écarts » et le KPI « Indice de conformité des demandes », en permettant de comparer les étapes d’approbation réellement suivies au circuit prévu. Les écarts peuvent signaler un non-respect des règles ou des inefficacités dans le processus. Pourquoi est-ce important ? Permet de vérifier la conformité en comparant le déroulement réel du processus à la hiérarchie d’approbation requise et de repérer les demandes non conformes. Où trouver ces données Cette information est configurée dans Oracle Fusion BPM Worklist ou dans Approval Management Engine (AMX). L’extraction du circuit défini pour chaque demande peut être complexe et nécessiter des requêtes dans les tables de configuration. Exemples Responsable > Directeur > Vice-président des financesResponsable du centre de coûts > Sécurité informatiqueResponsable > Chef de service
	Description de l’article ItemDescription	Description du produit ou du service demandé dans un poste de la demande.
Description Cet attribut contient la description textuelle de l’article à acheter et précise les biens ou les services demandés. Même si elle est souvent non structurée, la description de l’article apporte un contexte utile à l’analyse. Elle permet de filtrer les demandes portant sur des achats précis qui ne sont pas nécessairement identifiés par le type de demande. Un analyste peut, par exemple, rechercher toutes les demandes contenant « Licence logicielle » pour étudier leur parcours et leur temps de cycle. Pourquoi est-ce important ? Précise les biens ou les services achetés et permet de filtrer et d’analyser plus finement des catégories d’achats particulières. Où trouver ces données Cet attribut figure dans la table des postes de demande POR_REQUISITION_LINES_ALL, dans un champ comme ITEM_DESCRIPTION. Exemples Ordinateur portable 15 pouces, 16 Go de RAMServices de conseil, projet du quatrième trimestreRenouvellement annuel de la maintenance logicielle
	Devise CurrencyCode	Code de devise du montant de la demande, par exemple USD ou EUR.
Description Cet attribut indique la devise dans laquelle est exprimé le montant total de la demande. Les demandes des organisations internationales peuvent être établies 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 de devise permet de comparer les valeurs avec précision, soit en filtrant une seule devise, soit en convertissant tous les montants dans une devise commune. Pourquoi est-ce important ? Garantit la précision des analyses et des rapports financiers, notamment dans les organisations internationales qui utilisent plusieurs devises. Où trouver ces données Cet attribut figure généralement dans la table d’en-tête de la demande, à côté des champs de montant, par exemple dans POR_REQUISITION_HEADERS_ALL. Exemples USDEURGBPJPY
	Est automatisée IsAutomated	Indicateur précisant si une activité a été effectué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 articles de faible valeur. L’analyse de cet attribut permet de mesurer le degré d’automatisation du processus. Elle permet de comparer la rapidité et l’efficacité des étapes automatisées à celles des étapes manuelles, et de repérer d’autres possibilités d’automatisation. Pourquoi est-ce important ? Permet de mesurer le degré d’automatisation du processus et de repérer les tâches manuelles qui pourraient être automatisées. Où trouver ces données Cet attribut est déduit en vérifiant si l’utilisateur associé à une activité est un compte système ou de service. Il faut pour cela disposer d’une liste des identifiants d’utilisateurs système connus. 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 désigne la personne à l’origine de la demande, le nom de l’utilisateur indique qui a réalisé un événement précis du processus, comme une approbation ou un rejet. Cet attribut est particulièrement important lorsque plusieurs personnes interviennent dans les étapes d’approbation. Il est essentiel pour analyser les goulots d’étranglement liés aux approbations et mesurer les performances de certains approbateurs ou équipes. Il alimente directement le Dashboard « Goulots d’étranglement du flux d’approbation », qui permet d’analyser les durées de traitement pour chaque personne intervenant dans la chaîne d’approbation. Pourquoi est-ce important ? Identifie la personne à l’origine de chaque événement, ce qui permet d’analyser les délais de transfert, les performances des approbateurs et la répartition des ressources. Où trouver ces données Cet attribut provient de l’historique du flux de travail ou des tables de journaux d’audit, comme FA_FUSION_SOAINFRA.WFTASK, qui consigne l’utilisateur associé à la réalisation de chaque tâche. Exemples David LeeSusan ChenMichael Brown
	Nom du fournisseur SupplierName	Nom du fournisseur proposé ou présélectionné pour les biens ou les services.
Description Cet attribut identifie le fournisseur auprès duquel les biens ou les services doivent être achetés. Le demandeur peut proposer un fournisseur, ou le système peut le déterminer à partir des catalogues ou des accords existants. L’analyse par fournisseur peut révéler des tendances importantes en matière d’approvisionnement. Elle permet, par exemple, de voir si les demandes concernant certains fournisseurs mettent plus de temps à être approuvées ou sont plus souvent rejetées. Ces informations peuvent éclairer la gestion des relations fournisseurs et la stratégie d’approvisionnement. Pourquoi est-ce important ? Permet d’analyser les performances du processus par fournisseur et d’éclairer la stratégie d’approvisionnement ainsi que la gestion des relations fournisseurs. Où trouver ces données Cet attribut figure dans la table des postes de demande POR_REQUISITION_LINES_ALL. Il est souvent relié à une table de référence des fournisseurs comme POZ_SUPPLIERS au moyen du champ VENDOR_ID. Exemples Fournitures de bureau inc.Solutions technologiques mondialesAgence de marketing créatif
	Numéro du bon de commande PurchaseOrderNumber	Identifiant du bon de commande créé à partir de la demande approuvée.
Description Cet attribut relie une demande d’achat au bon de commande qui en résulte. Une fois entièrement approuvée, la demande est généralement convertie en un ou plusieurs bons de commande destinés au fournisseur. Cet identifiant est indispensable pour suivre les étapes qui suivent la demande. Il permet de calculer le KPI « Délai entre la demande et le bon de commande » et alimente le Dashboard « Temps de cycle entre la demande et le bon de commande ». Il permet également de combiner les données du processus de demande avec celles des processus de commande et de facturation, pour analyser l’ensemble du cycle d’approvisionnement au paiement. Pourquoi est-ce important ? Relie la demande au bon de commande qui en découle, ce qui permet de mesurer le temps de cycle entre les deux et d’analyser le processus de bout en bout. Où trouver ces données Cette information est enregistrée lors de la création d’un bon de commande. Elle se trouve généralement en recherchant les références à la demande d’origine dans les tables de répartition des bons de commande, comme PO_DISTRIBUTIONS_ALL, qui renvoie au poste de la demande. Exemples PO-2023-5832PO-2023-5833PO-2023-5834
	Type de demande RequisitionType	Catégorie de la demande, par exemple une demande de biens ou de services.
Description Cet attribut classe la demande selon les biens ou services demandés. Les types courants comprennent les biens, les services et les dépenses d’investissement. Le type peut influer sur le circuit d’approbation requis et la stratégie d’approvisionnement. Dans l’analyse, le type de demande permet de filtrer les données et de comparer différentes catégories. Vous pouvez, par exemple, vérifier si les demandes de services ont un temps de cycle d’approbation plus long que les demandes de biens. Cet attribut aide à déterminer si les types de demandes suivent des parcours différents ou présentent des goulots d’étranglement particuliers. Pourquoi est-ce important ? Permet de segmenter l’analyse pour comparer le déroulement du processus selon le type d’achat, par exemple entre les biens et les services. Où trouver ces données Cet attribut est souvent déterminé par le type ou la catégorie de poste sélectionné lors de la création de la demande. Il peut être stocké dans la table des postes de demande POR_REQUISITION_LINES_ALL. Exemples BiensServicesDépenses d’investissement

Obligatoire Recommandé Facultatif

Activités des demandes d’achat, de la commande au paiement

Voici les principales étapes et les jalons à enregistrer dans votre journal d’événements pour découvrir avec précision le processus de demande d’achat, de la commande au paiement.

6 Recommandé 6 Facultatif

	Activité	Description
	Bon de commande créé	Cet événement se produit lorsqu’une ligne de demande approuvée sert à générer un bon de commande. Il relie le processus de demande d’achat au processus d’achat qui suit.
Pourquoi est-ce important ? Cette étape est importante pour mesurer le délai entre la demande et le bon de commande. Les retards à ce stade révèlent des goulots d’étranglement lors du transfert entre l’approbation et les achats. Où trouver ces données Il s’agit d’un événement explicite. Le lien entre la demande et le bon de commande est enregistré dans des tables comme PO_LINE_LOCATIONS_ALL, qui contient une référence à l’identifiant de la ligne de demande source. Données à recueillir Recherchez la date de création du bon de commande associé à l’identifiant de demande concerné. Type d’événement explicit
	Demande d’achat approuvée	Marque l’approbation finale de la demande d’achat, après validation de toutes les étapes du flux de travail. L’événement est déduit du passage du statut général de la demande à « Approuvé ».
Pourquoi est-ce important ? Cette étape importante indique que la demande est prête à être traitée par le service des achats. Elle marque la fin du temps de cycle total d’approbation de la demande. Où trouver ces données L’événement est déduit du passage du champ de statut du document à « APPROVED » dans la table POR_REQUISITION_HEADERS_ALL. La date de ce changement de statut correspond à l’heure de l’événement. Données à recueillir Repérez l’horodatage auquel le statut du document passe pour la première fois à « Approuvé ». Type d’événement inferred
	Demande d’achat clôturée	Indique la clôture définitive du cycle de vie de la demande, lorsque toutes ses lignes ont été traitées, par exemple converties en bons de commande, ou annulées. L’événement est déduit d’une mise à jour finale du statut.
Pourquoi est-ce important ? Il s’agit de l’événement de fin qui marque l’aboutissement du processus. Il confirme que la demande a été entièrement traitée et qu’aucune autre action n’est nécessaire. Où trouver ces données L’événement est déduit du passage du statut de l’en-tête de demande à « CLOSED » dans POR_REQUISITION_HEADERS_ALL. Données à recueillir Repérez l’horodatage auquel le statut du document de la demande passe à « Closed ». Type d’événement inferred
	Demande d’achat créée	Marque le début du processus d’achat, lorsque l’utilisateur enregistre une nouvelle demande d’achat pour la première fois. Cet événement est généralement enregistré explicitement dans le système, avec un horodatage.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus de demande d’achat. L’analyse du délai entre la création et la soumission peut révéler des retards dans la formalisation de la demande. Où trouver ces données Cet événement est enregistré dans la table POR_REQUISITION_HEADERS_ALL, à partir de la colonne creation_date, lorsqu’un nouvel identifiant de demande est généré. Données à recueillir Utilisez l’horodatage de création de l’enregistrement d’en-tête de la demande. Type d’événement explicit
	Demande d’achat rejetée	Correspond au rejet définitif de la demande, qui met fin au processus pour cette demande. L’événement est déduit du passage du statut général de la demande à « Rejected ».
Pourquoi est-ce important ? Cette activité marque la fin d’une demande qui n’a pas abouti. L’analyse de ces cas est essentielle pour comprendre le KPI du taux de rejet des demandes d’achat et les causes des échecs. Où trouver ces données L’événement est déduit du passage du statut du document à « REJECTED » dans la table POR_REQUISITION_HEADERS_ALL. Données à recueillir Repérez l’horodatage auquel le statut du document passe pour la première fois à « Rejected ». Type d’événement inferred
	Demande d’achat soumise	Correspond à l’action par laquelle l’utilisateur soumet la demande remplie au flux de travail d’approbation. L’événement est enregistré lorsque le statut passe de « Incomplete » ou « Brouillon » à un statut indiquant que l’approbation est en attente.
Pourquoi est-ce important ? Cette activité déclenche le cycle d’approbation. Elle constitue une étape importante pour mesurer le temps de cycle d’approbation des demandes et les délais globaux. Où trouver ces données Déduit d’un changement de statut dans la table POR_REQUISITION_HEADERS_ALL, par exemple lorsque le statut devient « PENDING APPROVAL ». La date de soumission est souvent également enregistrée explicitement. Données à recueillir Repérez l’horodatage du premier passage du champ de statut du document à « Pending Approval ». Type d’événement inferred
	Demande d’achat modifiée	Cet événement indique qu’un utilisateur a modifié une demande après sa soumission initiale, ce qui peut entraîner la reprise du processus d’approbation. Il est déduit des changements apportés aux champs de données clés ou de la création d’une nouvelle version de la demande.
Pourquoi est-ce important ? Des modifications fréquentes peuvent révéler des problèmes de qualité des données ou des exigences qui évoluent, et entraîner des reprises et des retards. Cet événement contribue directement au KPI « Taux de modification des demandes d’achat ». Où trouver ces données L’événement est déduit du suivi des numéros de version de la demande ou du repérage d’un retour au statut « Incomplete » après la soumission. Les journaux de modifications ou les tables d’audit peuvent également enregistrer ces changements. Données à recueillir Repérez les horodatages de création de nouvelles versions pour un même identifiant de demande après sa soumission. Type d’événement inferred
	Demande d’achat retirée	Cet événement se produit lorsque le demandeur annule ou retire une demande 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 est-ce important ? Le suivi des retraits aide à comprendre les raisons d’un arrêt prématuré, comme un changement des besoins ou la correction d’erreurs par les utilisateurs après la soumission. Où trouver ces données Déduit du passage au statut « WITHDRAWN » dans la table POR_REQUISITION_HEADERS_ALL. L’action figure dans l’historique des actions de la demande. Données à recueillir Repérez l’horodatage auquel le statut de la demande passe à « Withdrawn ». Type d’événement inferred
	Étape d’approbation approuvée	Correspond à l’action par laquelle un approbateur approuve la demande à l’étape qui lui est attribuée dans le flux de travail. L’événement est explicitement enregistré dans l’historique des approbations.
Pourquoi est-ce important ? Le suivi de chaque étape d’approbation permet de cartographier le parcours réel et de mesurer le temps de traitement à chaque niveau de la hiérarchie. Où trouver ces données L’événement est extrait de l’historique des actions d’approbation de la demande, généralement stocké dans les tables de flux de travail (WF) ou de gestion du capital humain (HCM) qui gèrent les hiérarchies d’approbation. Données à recueillir Utilisez l’horodatage de l’action « APPROVE » dans le journal des actions du flux de travail. Type d’événement explicit
	Étape d’approbation commencé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’événement est enregistré dans le journal des transactions du moteur de flux de travail.
Pourquoi est-ce important ? Cette activité est nécessaire pour calculer le temps d’attente à chaque étape d’approbation. Elle aide à repérer les goulots d’étranglement liés à certains approbateurs ou niveaux d’approbation. Où trouver ces données L’information provient 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é. Données à recueillir 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, qui est généralement renvoyée à son préparateur pour correction ou clôturée. Cette action est explicitement enregistrée dans l’historique du flux de travail.
Pourquoi est-ce important ? Cette activité est une cause majeure de reprises et de retards. L’analyse des rejets aide à repérer les problèmes de conformité, les difficultés budgétaires ou les justifications peu claires. Où trouver ces données L’événement est extrait de l’historique des actions d’approbation de la demande. Le système de flux de travail enregistre une action « REJECT » avec un horodatage. Données à recueillir Utilisez l’horodatage de l’action « REJECT » dans le journal des actions du flux de travail. Type d’événement explicit
	Étape d’approbation renvoyée	Un approbateur renvoie la demande à son préparateur pour obtenir des informations supplé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 est-ce important ? Ce retour signale un besoin de clarification et crée une boucle de reprise qui allonge le temps de cycle. Distinguer les retours des rejets permet de mieux comprendre les difficultés du processus. Où trouver ces données L’événement est 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 un horodatage. Données à recueillir 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 extraire vos données d’Oracle Fusion Financials

Étapes

Accédez à Rapports et analyses : Connectez-vous à Oracle Fusion Financials. Dans le menu Navigator, accédez à Tools, puis sélectionnez Reports and Analytics. Cet espace central regroupe 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 domaine : Vous serez invité à choisir un domaine. Dans le champ de recherche, saisissez « Procurement - Requisitions Real Time », puis sélectionnez-le dans la liste. Ce domaine contient 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 de fonction UNION ALL directe pour différents types d’événements, vous allez créer un rapport unique qui rassemble 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 » à gauche vers la zone « Selected Columns ». Ajoutez notamment les colonnes de date de création, de soumission, d’approbation, de création de commande, etc.
Ajoutez l’historique des actions de la demande : Pour enregistrer les étapes détaillées d’approbation (approuvée, rejetée, renvoyée, retirée), ajoutez les champs du dossier « Requisition Action History » dans le domaine. Faites glisser « Action Date », « Action » et « Performer » dans les colonnes sélectionnées.
Configurez les filtres : Passez à l’onglet « Prompts » pour créer des filtres pour votre analyse. Il est essentiel de limiter le volume de données en définissant une période. 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 examinez le rapport : Ouvrez l’onglet « Results » pour exécuter l’analyse et prévisualiser les données. Le résultat sera un tableau « large », avec une ligne par ligne de demande ou 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 des résultats. Choisissez « Data » > « CSV File » comme format. Les données brutes de votre analyse seront téléchargées.
Transformez les données au format journal d’événements : Le fichier CSV exporté est au format large. Vous devez utiliser un outil externe, par exemple un script Python, Power Query dans Excel ou un autre outil de préparation des données, pour le transformer. Il faut dépivoter les colonnes de dates dans une seule colonne « EventTime » et créer une colonne « ActivityName » correspondante pour chaque type d’événement (par exemple, « Requisition Created », « Requisition Submitted »).
Finalisez et préparez l’importation : Après la transformation, vérifiez que le fichier contient les colonnes requises : PurchaseRequisitionId, ActivityName, EventTime, SourceSystem et LastDataUpdate. Enregistrez le journal d’événements final au format CSV pour pouvoir l’importer dans ProcessMind.

Configuration

Domaine : Le domaine principal à utiliser est « Procurement - Requisitions Real Time ». Il contient les informations essentielles sur les en-têtes et les lignes de demande, les répartitions et l’historique des approbations.
Période : Appliquez toujours un filtre obligatoire sur les dates afin de limiter le volume de données et d’améliorer les performances. Pour commencer, filtrez « Requisition Header » . « Requisition Creation Date » sur les trois à six derniers mois.
Filtres clés : Vous pouvez ajouter des filtres sur « Requisition Header » . « Business Unit » et « Requisition Header » . « Requisition Status » pour cibler les unités organisationnelles pertinentes et exclure les statuts inutiles, comme « Canceled », si l’analyse ne les nécessite pas.
Sélection des colonnes : Choisissez avec soin les colonnes à ajouter à l’analyse. En inclure trop, notamment depuis de nombreux dossiers (dimensions), peut nuire aux performances. Limitez-vous aux champs nécessaires au journal d’événements.
Autorisations : La personne qui exécute l’extraction doit disposer d’un rôle lui donnant accès à l’espace de travail Reports and Analytics et au domaine « Procurement - Requisitions Real Time ». Les rôles « BI Author » et « Procurement Analyst » disposent généralement de ces autorisations.

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 compte 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 modèle de données, 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 fenêtre du nouveau Data Set, saisissez un nom (par exemple, Requisition_Event_Log), sélectionnez la source de données adaptée à vos données Financials (par exemple, ApplicationDB_FSCM) et définissez le type SQL sur « Standard SQL ».
Copiez le script SQL complet de 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 détecte automatiquement. Vous pouvez définir des valeurs par défaut si vous le souhaitez.
Enregistrez le modèle de données 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 modèle de données que vous venez de créer.
Exécutez le rapport en indiquant les dates de début et de fin. Une fois les données affichées, utilisez la fonction « Export » pour télécharger les résultats au format CSV.
Vérifiez que le fichier CSV final est enregistré en UTF-8 et contient les en-têtes requis pour l’importation 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 de façon similaire, doit être configurée avec un compte disposant d’un accès en lecture à toutes les tables de la requête, notamment celles de Procurement (POR, PO), Human Capital Management (PER, HR) et Financials (FUN).
Filtrage par période : La requête utilise les paramètres de date obligatoires (:p_start_date et :p_end_date) pour filtrer les demandes selon leur date de création. Pour les premières extractions ou les grands systèmes, il est essentiel de traiter les données par lots raisonnables, par exemple trois à six mois à la fois, afin d’éviter les délais d’expiration du système.
Filtrage par unité opérationnelle : La clause WHERE de la requête contient un filtre commenté sur le nom de l’unité opérationnelle. Il est vivement recommandé de décommenter et de configurer ce filtre pour limiter les données aux unités pertinentes pour votre analyse, ce qui peut améliorer sensiblement les performances.
Prérequis : La personne qui crée et exécute le rapport doit disposer d’un rôle lui donnant accès à BI Publisher, tel que « BI Administrator Role » ou « BI Author Role ». Elle doit également bénéficier des autorisations de sécurité nécessaires pour accéder aux données d’approvisionnement.

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 API (nom d’utilisateur et mot de passe) d’un compte Oracle Fusion disposant des autorisations nécessaires 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 de remplacement en haut du fichier. Renseignez FUSION_URL, USERNAME et PASSWORD selon votre environnement Oracle Fusion. Ajustez START_DATE et END_DATE pour définir la période d’extraction.
Repérez les points de terminaison et les champs de l’API : Le script interroge la ressource de l’API REST purchaseRequisitions. Le paramètre fields limite la requête aux données nécessaires, y compris les collections imbriquées telles que lines (pour les informations de commande) et actionHistory (pour les événements d’approbation), ce qui améliore les performances.
Exécutez le script : Lancez-le depuis votre terminal avec la commande python extract_requisitions.py. Le script s’authentifie auprès de l’API, commence à récupérer les données et affiche la progression dans la console, notamment le nombre de demandes traitées.
Gérez la pagination : Le script gère automatiquement la pagination. L’API REST Oracle Fusion renvoie les données par lots (pages). Pour chaque réponse, le script vérifie l’indicateur hasMore et envoie de nouvelles requêtes avec un paramètre offset mis à jour jusqu’à ce que toutes les demandes de la période définie aient été récupérées.
Logique de transformation des données : Pour chaque demande récupérée via l’API, le script génère plusieurs lignes dans le journal d’événements. 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 un événement détaillé pour chaque étape d’approbation (Started, Approved, Rejected, Returned).
Déduisez les événements de statut final : Le script enregistre les événements de résultat final, comme « Requisition Approved » et « Requisition Rejected », en vérifiant le DocumentStatus final de la demande et en utilisant LastUpdateDate comme horodatage de l’événement.
Générez l’événement de commande : Le script examine chaque ligne de demande. Si une ligne comporte un PoHeaderId, cela indique qu’une commande a été créée. Une entrée est alors ajoutée au journal d’événements pour cette activité, qui relie la demande au processus d’approvisionnement en aval.
Vérifiez le fichier de sortie : Une fois le script exécuté, il crée un fichier CSV nommé oracle_fusion_requisitions_event_log.csv dans le même répertoire. Ce fichier contient le journal d’événements extrait.
Préparez l’importation : Ouvrez le fichier CSV généré dans un tableur pour 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 prêt à être importé dans ProcessMind.

Configuration

Identifiants API : Un compte d’intégration dédié, associé à un rôle donnant un accès en lecture seule à l’API REST Purchase Requisitions, est nécessaire. Il peut s’agir, par exemple, du rôle Procurement Manager ou d’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 comprend les variables START_DATE et END_DATE. Il est vivement recommandé d’extraire les données par lots raisonnables, par exemple trois à six mois à la fois, afin d’éviter les délais d’expiration de l’API et les problèmes de performance. Le filtre porte sur la CreationDate des demandes.
Sélection des champs : Le paramètre fields du script est essentiel aux performances. Il limite la réponse aux seuls attributs nécessaires au journal d’événements, 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 l’extraction, mais une valeur trop élevée peut entraîner des problèmes de mémoire ou atteindre les limites de l’API.

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 d’approvisionnement Oracle Fusion Financials requis et l’accès aux Public View Objects concernés sont disponibles dans votre environnement. Confirmez que le compte utilisateur ou d’intégration BICC est autorisé à extraire les données des demandes d’achat, de l’historique des approbations et des commandes. Les noms exacts des rôles et des options de navigation varient selon la version d’Oracle. Utilisez l’espace d’administration BICC correspondant dans votre environnement.
Identifiez et activez les PVO nécessaires à l’extraction. Utilisez RequisitionHeaderPVO, ou le PVO d’en-tête de demande correspondant dans votre environnement, ainsi que les PVO qui exposent les lignes de demande, l’historique des statuts, l’historique du flux de travail d’approbation et les références de commande. Ne partez pas du principe qu’un seul PVO contient l’historique du flux de travail ou celui de la création des commandes. Notez les noms exacts des PVO et les attributs disponibles dans votre environnement.
Configurez une tâche BICC pour une extraction incrémentielle ou historique en masse. Définissez la période d’extraction à l’aide de [Start date parameter] et [End date parameter], puis configurez la tâche pour qu’elle dépose les fichiers CSV dans l’emplacement de stockage cloud approuvé. Pour le chargement initial, choisissez une période historique suffisamment large. Pour les chargements récurrents, faites se chevaucher les périodes 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, s’il est disponible, de l’identifiant de l’événement source.
Configurez les colonnes à extraire. Incluez l’identifiant de la demande, les identifiants de l’en-tête et des lignes, 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 de changement de statut, les horodatages d’affectation et d’action d’approbation, l’action d’approbation, la référence de commande 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 à [Configure based on your system] et consignez cette limite au lieu de le remplacer par un champ dont la validité n’a pas été vérifiée.
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 celui du fichier, normalisez les horodatages selon un même fuseau horaire convenu et analysez les valeurs de date et d’horodatage Oracle de manière cohérente. Traitez les identifiants comme des chaînes de caractères afin de préserver les zéros initiaux et la précision.
Transformez les données sources en une table d’événements comportant 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 une ligne pour chacune des douze activités indiquées dans la requête.
Créez les lignes d’événement à partir des éléments de preuve 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 une transition explicite de retrait pour Requisition Withdrawn, une modification détectée après la soumission ou une nouvelle version pour Requisition Amended, l’affectation au 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. Pour Purchase Order Created, utilisez un enregistrement explicite de création de commande ou son horodatage, lié à la demande.
Appliquez une déduplication déterministe. Si plusieurs lignes sources représentent le même événement, conservez-en une en utilisant l’horodatage d’événement le plus précis et, s’il est disponible, un identifiant source stable. 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 chaque approbateur ou étape du flux de travail.
Validez le journal d’événements obtenu. Vérifiez que toutes les activités requises sont représentées, que chaque événement comporte 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 le nombre de demandes et les liens vers les commandes 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 de données en masse avec Oracle BI Cloud Connector, les fichiers CSV étant déposés dans l’emplacement de stockage cloud configuré.
Objets sources : utilisez RequisitionHeaderPVO et les PVO correspondants disponibles dans votre environnement pour les lignes de demande, l’historique des statuts, l’historique du flux de travail d’approbation et les références de commande. Vérifiez les noms exacts des PVO et des attributs dans votre environnement.
Colonnes de sortie requises : 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 les analyses courantes. Pour un premier chargement historique, choisissez une période plus large si nécessaire. Pour les extractions récurrentes, faites se chevaucher les périodes afin de capturer les mises à jour tardives, puis dédupliquez les données.
Filtres : appliquez [Company-specific filter], [Document Type filter], [Business Unit filter] et [Date range filter] uniquement si ces attributs sont disponibles dans les PVO sélectionnés. Vérifiez si le filtre porte sur la date de création, la date de mise à jour, la date de transition 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 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 si les en-têtes de demande n’exposent pas l’historique des approbations, les transitions de statut, les modifications ou la création des commandes. Une extraction des seuls en-têtes dans leur état actuel ne permet pas de reconstituer de manière fiable les événements historiques.
Performances : limitez la période et le nombre de colonnes sélectionnées, répartissez les extractions volumineuses en partitions si cette option est disponible, évitez les attributs descriptifs superflus et traitez les fichiers CSV par lots. Conservez les fichiers sources pour les rapprochements.
Stockage : configurez un emplacement de stockage cloud approuvé disposant d’une capacité suffisante, avec des règles de conservation, de chiffrement et de contrôle des accès adaptées. Vérifiez que le compte d’extraction peut y écrire des 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 concernées, autorisations d’intégration appropriées, accès aux PVO sélectionnés et tout abonnement Oracle ou droit d’utilisation de fonctionnalité 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 de l’environnement.
Gestion des dates et heures : normalisez tous les horodatages sources selon un fuseau horaire documenté et conservez l’horodatage d’origine lorsque la traçabilité est nécessaire.
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.

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 de demande d’achat, de la commande au paiement, et gagner en efficacité. Préparez-vous à transformer vos opérations d’achat.

Retour au guide d’amélioration

Télécharger le modèle

Accélérez de 30 % le processus de demande d’achat, de la commande au paiement

Optimisez le traitement des demandes d’achat P2P dans Oracle et réduisez le temps de cycle de 30 %.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

Votre modèle de données pour les demandes d’achat, de la commande au paiement

Votre modèle de données pour les demandes d’achat, de la commande au paiement

Attributs des demandes d’achat, de la commande au paiement

Activités des demandes d’achat, de la commande au paiement

Guides d’extraction

Export Oracle Transactional Business Intelligence (OTBI)

Étapes

Configuration

Exemple de requête sql

Extraction de données SQL avec Oracle BI Publisher

Étapes

Configuration

Exemple de requête sql

Script Python via l’API REST Oracle Fusion

Étapes

Configuration

Exemple de requête python

Extraction de données en masse avec Oracle BI Cloud Connector (BICC)

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Accélérez de 30 % le processus de demande d’achat, de la commande au paiement

Votre modèle de données pour les demandes d’achat, de la commande au paiement

Votre modèle de données pour les demandes d’achat, de la commande au paiement

Attributs des demandes d’achat, de la commande au paiement

Activités des demandes d’achat, de la commande au paiement

Guides d’extraction

Export Oracle Transactional Business Intelligence (OTBI)

Étapes

Configuration

Exemple de requête sql

Extraction de données SQL avec Oracle BI Publisher

Étapes

Configuration

Exemple de requête sql

Script Python via l’API REST Oracle Fusion

Étapes

Configuration

Exemple de requête python

Extraction de données en masse avec Oracle BI Cloud Connector (BICC)

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Accélérez de 30 % le processus de demande d’achat, de la commande au paiement

Prêt à commencer ?