> Amélioration Continue des Processusus > Achats au paiement : demande d'achat > Oracle Fusion Financials > Template de données

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Oracle Fusion Financials

← Retour au Guide d'amélioration

Achats au paiement : attributs de demande d'achat (22) Achats au paiement – Activités de demande d'achat (12) Guides d'extraction (4)

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Ce modèle fournit les étapes nécessaires à la collecte des données essentielles nécessaires à l'analyse de vos processus Achats au paiement (P2P) - Réquisition. Il décrit les attributs clés à collecter, les activités critiques à suivre et des conseils pratiques sur la façon d'extraire ces informations d'Oracle Fusion Financials. Grâce à cela, vous pouvez préparer efficacement votre journal d'événements pour une analyse de Process Mining détaillée.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction pour Oracle Fusion Financials

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Achats au paiement : attributs de demande d'achat

Voici les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète du processus Achats au paiement (P2P) - Réquisition.

5 Obligatoire 7 Recommandé 10 Facultatif

	Nom	Descriptionn
	Activité ActivityName	Le nom de l'événement commercial qui s'est produit à un point spécifique du processus de réquisition.
Descriptionn L'activité représente une étape ou un jalon distinct dans le cycle de vie de la réquisition d'achat. Les exemples incluent 'Réquisition créée', 'Étape d'approbation approuvée' ou 'Bon de commande créé'. Ces activités sont dérivées des changements de statut, des actions des utilisateurs ou des événements système enregistrés dans les journaux d'audit ou les tables de transactions du système source. Cet attribut est indispensable pour construire la cartographie des processus, qui représente visuellement le flux des réquisitions. L'analyse de la séquence et de la fréquence des activités aide à identifier les chemins de processus courants, les points de blocage, les boucles de reprise et les écarts par rapport à la procédure standard. Pourquoi est-ce important ? : Il sert de base à la cartographie des processus, pour visualiser et l'analyse du workflow de réquisition. Source des données : Dérivé des enregistrements de changement de statut dans des tables comme POR_REQUISITION_HEADERS_ALL, l'historique des transactions ou les pistes d'audit de workflow comme FA_FUSION_SOAINFRA.WFTASK. Exemples Demande d'achat crééeÉtape d'approbation approuvéeDemande rejetéeCommande d'achat créée
	Heure de l'événement EventTime	L'horodatage indiquant quand l'activité a eu lieu.
Descriptionn L'heure de l'événement enregistre la date et l'heure précises auxquelles une activité spécifique a eu lieu. Cet horodatage est indispensable pour l'ordonnancement chronologique des événements au sein d'un dossier et provient des dates de création, des dates de dernière mise à jour ou des horodatages d'actions spécifiques dans le système. En analyse, l'heure de l'événement est utilisée pour calculer toutes les métriques basées sur la durée, telles que les temps de cycle entre les activités, les temps d'attente et la durée globale du dossier. Elle est indispensablele pour identifier les points de blocage, mesurer les performances par rapport aux SLA et comprendre la dynamique temporelle du processus de réquisition. Pourquoi est-ce important ? : Cet attribut est indispensable pour calculer tous les KPI liés au temps, ordonner correctement les événements et analyser les performances et les points de blocage du processus. Source des données : Ceci provient généralement d'une colonne 'LAST_UPDATE_DATE' ou 'CREATION_DATE' associée à la transaction ou au changement de statut, souvent trouvée dans des tables comme POR_REQUISITION_HEADERS_ALL ou les tables d'historique de workflow. Exemples 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ID de la demande d'achat PurchaseRequisitionId	L'identifiant unique d'une réquisition d'achat, servant d'ID de dossier pour le processus.
Descriptionn L'ID de la réquisition d'achat est l'identifiant central qui relie toutes les activités liées à une demande spécifique de biens ou de services. Chaque réquisition se voit attribuer un ID unique lors de sa création, qui reste constant tout au long de son cycle de vie. Dans le Process Mining, cet attribut est utilisé pour regrouper tous les événements connexes, tels que la création, la soumission, les étapes d'approbation et la clôture finale, en un seul dossier. Cela permet l'analyse complet du parcours de la réquisition, rendant possible la visualisation des cartes de processus, le calcul des temps de cycle et l'analyse des variantes pour chaque demande individuelle. Pourquoi est-ce important ? : C'est l'attribut clé pour suivre le cycle de vie d'une réquisition du début à la fin, permettant toutes les analyses au niveau du dossier et les calculs de KPI. Source des données : Il s'agit généralement de la clé primaire de la table d'en-tête de réquisition, comme POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID dans Oracle Fusion Financials. Exemples 100234810023491002350
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la dernière actualisation des données depuis le système source.
Descriptionn Cet attribut indique la date et l'heure de la dernière extraction des données d'Oracle Fusion Financials. Il s'applique à l'ensemble du jeu de données plutôt qu'aux événements individuels. Les analystes utilisent cette information pour comprendre la la réactualisation des données et pour confirmer quand les dernières transactions ont été incluses. Il est indispensable des métadonnées pour les rapports de tableau de bord et pour s'assurer que les analyses sont basées sur des informations à jour. Pourquoi est-ce important ? : Informe les utilisateurs de la la réactualisation des données, garantissant ainsi que les analyses sont pertinentes et basées sur les informations les plus récentes. Source des données : Cet horodatage est généré et stocké pendant le processus d'extraction de 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	Le système d'information à partir duquel ces données ont été extraites.
Descriptionn Cet attribut identifie l'origine des données de processus. Pour ce modèle de données, il sera toujours 'Oracle Fusion Financials'. Dans les environnements avec plusieurs ERP ou systèmes intégrés, ce champ est impératif pour la traçabilité des données, le dépannage et l'assurance de la qualité des données. Il fournit un contexte sur la source de vérité des événements de processus analysés. Pourquoi est-ce important ? : Fournit un contexte essentiel sur l'origine des données, essentiel pour la gouvernance des données et lors de l'intégration de données provenant de plusieurs systèmes. Source des données : C'est une valeur statique ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter l'origine de l'ensemble de données. Exemples Oracle Fusion Financials
	`Date requise` RequiredByDate	La date à laquelle le demandeur a besoin des biens ou services.
Descriptionn Cette date est spécifiée par le demandeur pour indiquer la date limite de réception des articles demandés. Elle sert de cible d'accord de niveau de service (SLA) interne pour le processus d'approvisionnement. Cet attribut est le fondement du tableau de bord 'Performance des dates de besoin' et du KPI 'Taux de résolutionpect des dates de besoin'. En comparant cette date avec la date réelle de création du bon de commande ou la date de réception des marchandises, l'analyse peut révéler dans quelle mesure le processus d'approvisionnement répond aux demandes des clients internes et identifier les retards systémiques. Pourquoi est-ce important ? : Primordial pour mesurer la performance des processus par rapport aux délais internes et comprendre si le processus d'approvisionnement répond aux besoins de l'entreprise dans les délais. Source des données : Généralement stocké au niveau de la ligne d'article de réquisition, dans des tables comme POR_REQUISITION_LINES_ALL dans un champ tel que 'NEED_BY_DATE'. Exemples 2023-11-012023-12-152024-01-31
	Département DepartmentName	Le service commercial auquel appartient le demandeur.
Descriptionn Cet attribut indique l'unité organisationnelle de la personne qui a créé la réquisition, telle que 'Finance', 'IT' ou 'Marketing'. Il est généralement dérivé du profil utilisateur du demandeur dans le système RH. L'analyse par service est un moyen courant et puissant de segmenter les données de processus. Elle aide à identifier les comportements spécifiques aux services, tels que des taux de rejet plus élevés ou des temps de cycle plus longs, ce qui peut éclairer des initiatives d'amélioration de processus ciblées. C'est une dimension clé pour le tableau de bord 'Requester Performance Metrics'. Pourquoi est-ce important ? : Permet une analyse de processus segmentée par unité commerciale, mettant en évidence les tendances, les performances et les problèmes de conformité spécifiques à chaque département. Source des données : Généralement dérivé du profil du demandeur, nécessitant souvent une jointure entre la table de réquisition et une table RH ou un annuaire d'utilisateurs contenant les informations du service. Exemples Technologies de l'InformationFinanceOpérationsMarketing
	Montant total de la demande d'achat RequisitionTotalAmount	La valeur monétaire totale de la demande d'achat.
Descriptionn Cet attribut représente la somme de la valeur de toutes les lignes d'articles d'une seule réquisition d'achat. C'est un point de données essentiel pour comprendre l'importance financière de chaque demande. Dans le Process Mining, le montant total est utilisé pour un large éventail d'analyses. Il peut être utilisé pour filtrer les réquisitions de grande valeur, qui ont souvent des chemins d'approbation différents ou une surveillance plus stricte. Les dashboards peuvent utiliser cet attribut pour analyser la corrélation entre les métriques de processus, comme le temps de cycle ou le taux de rejet, et la valeur de la réquisition. Pourquoi est-ce important ? : Fournit un contexte financier, permettant une analyse basée sur la valeur pour prioriser les améliorations de processus et comprendre comment la valeur de la réquisition impacte le comportement du processus. Source des données : Situé dans l'en-tête de la réquisition, souvent dans un champ comme REQUISITION_TOTAL dans POR_REQUISITION_HEADERS_ALL. Il peut également être calculé en additionnant les montants des lignes d'articles de POR_REQUISITION_LINES_ALL. Exemples 550.0012500.7599.99
	Motif de refus RejectionReason	Le motif fourni par un approbateur lorsqu'une réquisition ou une étape d'approbation est rejetée.
Descriptionn Lorsqu'une réquisition est rejetée, l'approbateur fournit généralement un motif, soit en le sélectionnant dans une liste prédéfinie, soit en saisissant du texte libre. Cet attribut capture cette justification. C'est un attribut critique pour l'analyse des causes profondes des échecs de processus. Il prend directement en charge le tableau de bord 'Tendances des modifications et des rejets' en fournissant le 'pourquoi' des rejets. L'analyse des motifs de rejet aide à identifier les problèmes courants, tels que des codifications incorrectes, des dépassements de budget ou des violations de politiques, qui peuvent ensuite être traités par des formations ou des contrôles système. Pourquoi est-ce important ? : Offre un aperçu direct des raisons de rejet des réquisitions, permettant des améliorations ciblées pour réduire les reprises et augmenter le taux de traitement direct. Source des données : Provient des commentaires de workflow ou des champs de codes de motif de rejet spécifiques dans le journal d'audit du workflow, potentiellement dans tables liées à FA_FUSION_SOAINFRA.WFTASK ou au stockage des commentaires associé. Exemples Compte GL incorrectDépasse le budget du centre de coûtsFournisseur non privilégié sélectionnéDemande en double
	Nom du Demandeur RequesterName	Le nom de l'employé qui a créé et soumis la réquisition d'achat.
Descriptionn Cet attribut identifie la personne qui a initié la demande de biens ou de services. Cette information est généralement capturée au début du processus, lors de la première création de la réquisition. L'analyse de la performance du processus par demandeur est indispensablele pour le tableau de bord 'Requester Performance Metrics'. Elle aide à identifier les utilisateurs ou groupes qui pourraient nécessiter une formation supplémentaire en mettant en évidence des taux élevés de modifications, de rejets ou des temps de cycle longs associés à leurs demandes. Elle offre une vue du processus centrée sur l'humain. Pourquoi est-ce important ? : Permet l'analyse des performances par demandeur, aidant à identifier les besoins en formation et à mettre en évidence les utilisateurs ou les départements efficaces. Source des données : Provient des données d'en-tête de réquisition, souvent en joignant l'ID du demandeur à une table maître d'employés ou d'utilisateurs. Recherchez les champs liés à 'PREPARER_ID' dans POR_REQUISITION_HEADERS_ALL et joignez-les à PER_ALL_PEOPLE_F. Exemples John SmithJane DoeEmily Jones
	Statut de la demande RequisitionStatus	Le statut actuel ou final de la demande d'achat.
Descriptionn Cet attribut indique l'état général de la réquisition à un moment donné ou son résultat final, tel que 'Approuvée', 'Rejetée', 'En cours' ou 'Clôturée'. C'est souvent la source à partir de laquelle de nombreuses activités du journal d'événements sont dérivées. Cet attribut est indispensable pour le tableau de bord 'Requisition Status Overview', fournissant un aperçu de la charge de travail et du backlog actuels. Il est également utilisé pour calculer des KPI basés sur les résultats, comme le taux de rejet des réquisitions, en filtrant les cas qui se terminent par un statut spécifique. Pourquoi est-ce important ? : Fournit un aperçu de l'état actuel des réquisitions et est utilisé pour déterminer les résultats finaux des calculs de KPI. Source des données : Trouvé dans la table d'en-tête de demande, généralement dans un champ comme 'DOCUMENT_STATUS' ou 'APPROVAL_STATUS' dans POR_REQUISITION_HEADERS_ALL. Exemples APPROUVÉIN PROCESSREJETÉRETIRÉ
	Unité commerciale BusinessUnit	L'unité commerciale spécifique dans l'organisation à laquelle appartient la réquisition.
Descriptionn L'unité commerciale (Business Unit) représente une entité légale ou fonctionnelle distincte dans l'entreprise pour laquelle la réquisition est effectuée. Il s'agit d'un regroupement organisationnel de niveau supérieur à un service. L'analyse des données par unité commerciale permet des comparaisons de performances de haut niveau entre les différentes parties de l'organisation. Cela aide la direction à comprendre si les inefficacités des processus sont localisées ou généralisées et où concentrer les efforts d'amélioration. C'est une dimension clé pour filtrer presque tous les dashboards et KPI. Pourquoi est-ce important ? : Fournit un contexte organisationnel de haut niveau, permettant la comparaison des performances et l'analyse stratégique entre les différentes parties de l'entreprise. Source des données : Il s'agit d'un champ organisationnel clé dans Oracle Fusion, généralement disponible dans l'en-tête de la réquisition dans des tables comme POR_REQUISITION_HEADERS_ALL. Exemples BU North AmericaBU EuropeSiège social
	Chemin du workflow d'approbation ApprovalWorkflowPath	La séquence prédéfinie d'approbateurs ou de groupes d'approbation requise pour la réquisition.
Descriptionn Cet attribut définit le processus d'approbation attendu et standard pour une réquisition donnée, basé sur les politiques de l'entreprise, en tenant compte de facteurs tels que le montant, le type et le service de la réquisition. Il représente le modèle de processus 'cible' ('to-be'). Le chemin du workflow d'approbation (Approval Workflow Path) est indispensable pour l'analyse de conformité. Il prend directement en charge le tableau de bord 'Analyse de la conformité et des écarts' et le KPI 'Indice de conformité des réquisitions' en permettant une comparaison directe des étapes d'approbation réelles par rapport au chemin prescrit. Les écarts peuvent indiquer des violations de politique ou des inefficacités de processus. Pourquoi est-ce important ? : Permet la vérification de conformité en comparant le flux de processus réel à la hiérarchie d'approbation requise, mettant en évidence les demandes non conformes. Source des données : Cette information est configurée dans la liste de travail BPM d'Oracle Fusion ou le moteur de gestion des approbations (AMX). L'extraction du chemin défini pour chaque réquisition peut être complexe et peut nécessiter l'interrogation de tables de configuration. Exemples Manager > Directeur > VP FinancePropriétaire du centre de coûts > Sécurité informatiqueManager > Chef de service
	Descriptionn de l'article ItemDescription	La description du produit ou service demandé sur une ligne de réquisition.
Descriptionn Cet attribut contient la description textuelle de l'article en cours d'approvisionnement. Il fournit des détails spécifiques sur les biens ou services demandés. Bien que souvent non structurée, la description de l'article (Item Descriptionn) fournit un contexte précieux pour l'analyse. Elle peut être utilisée dans les filtres pour isoler les réquisitions pour des types d'achats spécifiques qui pourraient ne pas être capturés par le type de réquisition. Par exemple, un analyste pourrait rechercher toutes les réquisitions contenant 'Licence logicielle' pour comprendre leur flux de processus spécifique et leur temps de cycle. Pourquoi est-ce important ? : Offre un contexte détaillé sur ce qui est acheté, permettant un filtrage et une analyse plus granulairesres de biens ou services spécifiques. Source des données : Situé dans la table des lignes d'articles de réquisition, POR_REQUISITION_LINES_ALL, dans un champ comme ITEM_DESCRIPTION. Exemples Ordinateur portable 15 pouces, 16 Go de RAMServices de conseil - Projet T4Renouvellement annuel de la maintenance logicielle
	Devise CurrencyCode	Le code de devise pour le montant de la réquisition, tel que USD ou EUR.
Descriptionn Cet attribut spécifie la devise dans laquelle le montant total de la réquisition est exprimé. Pour les organisations mondiales, les réquisitions peuvent être créées dans différentes devises. Il est indispensable pour interpréter et agréger correctement les données financières. Dans toute analyse impliquant des valeurs monétaires, le code de devise doit être utilisé pour garantir que les montants sont comparés avec précision, soit en filtrant pour une seule devise, soit en convertissant tous les montants en une devise commune. Pourquoi est-ce important ? : Assure une analyse financière et un reporting précis, en particulier dans les organisations multinationales traitant avec plusieurs devises. Source des données : Généralement trouvé sur la table d'en-tête de réquisition aux côtés des champs de montant, par exemple, dans POR_REQUISITION_HEADERS_ALL. Exemples USDEURGBPJPY
	Est Automatisé IsAutomated	Un indicateur signalant si une activité a été effectuée automatiquement par le système.
Descriptionn Cet attribut identifie les événements du processus qui ont été exécutés par un utilisateur système ou un agent automatisé plutôt que par un être humain. Des exemples pourraient inclure des changements de statut pilotés par le système ou des étapes d'approbation automatisées pour des articles de faible valeur. L'analyse de cet attribut aide à quantifier le niveau d'automatisation dans le processus. Il peut être utilisé pour comparer la rapidité et l'efficacité des étapes automatisées par rapport aux étapes manuelles et pour identifier les opportunités d'automatisation supplémentaire. Pourquoi est-ce important ? : Aide à mesurer le niveau d'automatisation dans le processus et à identifier les opportunités d'automatiser les tâches manuelles. Source des données : Déduit en vérifiant si l'utilisateur associé à une activité est un compte système ou de service. Cela nécessite une liste d'identifiants d'utilisateurs système connus. Exemples truefaux
	Est modifiée IsAmendedFlag	Un indicateur booléen qui est vrai si la demande a été modifiée au moins une fois.
Descriptionn Cet attribut calculé indique si une réquisition a subi des modifications après sa soumission initiale. Il est dérivé en vérifiant la présence d'une activité 'Réquisition modifiée' dans l'historique du dossier. Ce drapeau simplifie l'analyse et le calcul des KPI. Il est utilisé directement pour calculer le KPI 'Taux de modification des réquisitions' et pour identifier les cas qui ne sont pas traités complet. Il permet un filtrage et une comparaison faciles des métriques de processus entre les réquisitions modifiées et non modifiées. Pourquoi est-ce important ? : Simplifie le calcul du taux de modification et permet une comparaison facile entre les réquisitions modifiées et non modifiées. Source des données : Cet attribut n'est pas dans le système source mais est calculé lors de la transformation des données en fonction de la présence d'activités liées aux modifications dans le journal d'événements. Exemples truefaux
	Est un traitement direct IsStraightThrough	Un indicateur indiquant si la demande a été approuvée sans aucune modification ni rejet.
Descriptionn Cet indicateur calculé identifie les réquisitions qui ont traversé le processus de la soumission à l'approbation sans aucune boucle de reprises, telle que des modifications ou des rejets. Il signifie un processus parfaitement exécuté pour un cas unique. Cet attribut est la base du KPI 'Taux de réquisitions traitées complet' ('Straight-Through Requisition Rate'). L'analyse des caractéristiques des réquisitions traitées complet (par exemple, services, demandeurs ou types courants) peut révéler les meilleures pratiques et les opportunités d'automatisation. Inversement, l'analyse de celles qui ne sont pas traitées complet aide à identifier les principaux moteurs d'inefficacité. Pourquoi est-ce important ? : Mesure directement l'efficacité du processus et constitue la base du KPI Taux de demandes sans intervention, aidant à identifier les moteurs de reprises. Source des données : Cet attribut est calculé pendant la transformation des données. Un dossier est marqué comme vrai si aucune activité 'Réquisition modifiée' ou 'Étape d'approbation rejetée' n'est présente. Exemples truefaux
	Nom d'utilisateur UserName	Le nom de l'utilisateur qui a effectué une activité spécifique, tel qu'un approbateur ou un éditeur.
Descriptionn Alors que le Nom du demandeur identifie l'initiateur, le Nom de l'utilisateur spécifie la personne qui a exécuté un événement particulier dans le processus, tel qu'une approbation ou un rejet. Ceci est particulièrement important pour les workflows d'approbation en plusieurs étapes impliquant différents individus. Cet attribut est impératif pour analyser les points de blocage des approbations et mesurer la performance d'approbateurs ou d'équipes spécifiques. Il contribue directement au le tableau de bord « Goulots d'étranglement des workflows d'approbation » en permettant l'analyse des temps de traitement pour chaque utilisateur impliqué dans la chaîne d'approbation. Pourquoi est-ce important ? : Identifie l'acteur de chaque événement, ce qui est indispensable à analyser les temps de transfert, la performance des approbateurs et l'allocation des ressources. Source des données : Provient de l'historique de workflow ou des tables de journal d'audit, telles que FA_FUSION_SOAINFRA.WFTASK, qui enregistrent l'utilisateur associé à chaque achèvement de tâche. Exemples David LeeSusan ChenMichael Brown
	Nom du Fournisseur SupplierName	Le nom du fournisseur suggéré ou présélectionné pour les biens ou services.
Descriptionn Cet attribut identifie le fournisseur auprès duquel les biens ou services sont destinés à être achetés. Le fournisseur peut être suggéré par le demandeur ou déterminé par le système en fonction de catalogues ou d'accords préalables. L'analyse par fournisseur peut révéler des modèles d'approvisionnement importants. Par exemple, elle peut aider à identifier si les réquisitions pour certains fournisseurs prennent plus de temps à être approuvées ou ont des taux de rejet plus élevés. Cette information peut être précieuse pour la gestion des relations fournisseurs et la stratégie d'approvisionnement. Pourquoi est-ce important ? : Permet l'analyse des performances des processus par fournisseur, ce qui peut aider à la stratégie d'approvisionnement et à la gestion des relations avec les fournisseurs. Source des données : Situé dans la table des lignes d'articles de réquisition, POR_REQUISITION_LINES_ALL, souvent lié via un VENDOR_ID à une table maître de fournisseurs comme POZ_SUPPLIERS. Exemples Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
	Numéro de commande d'achat PurchaseOrderNumber	L'identifiant du bon de commande créé à partir de la réquisition approuvée.
Descriptionn Cet attribut lie une réquisition d'achat au bon de commande résultant. Une fois qu'une réquisition est entièrement approuvée, elle est généralement convertie en un ou plusieurs bons de commande à envoyer à un fournisseur. En analyse, cet ID est indispensable pour suivre le processus en aval de la réquisition. Il permet le calcul du KPI 'Délai de la réquisition au bon de commande' et prend en charge le tableau de bord 'Temps de cycle de la réquisition au bon de commande'. Il permet également de combiner les données du processus de réquisition avec les processus de bon de commande et de facturation subséquents pour une véritable analyse complet du processus Purchase-to-Pay. Pourquoi est-ce important ? : Lie la réquisition au bon de commande subséquent, permettant de mesurer le temps de cycle de la réquisition au BC et une analyse de processus complet. Source des données : Ces informationsns sont stockées une fois qu'un bon de commande est créé. Elles sont généralement trouvées en recherchant les références de réquisition sous-jacentes dans les tables de distribution des bons de commande, comme PO_DISTRIBUTIONS_ALL, qui renvoient à la ligne de réquisition. Exemples PO-2023-5832PO-2023-5833PO-2023-5834
	Type de réquisition RequisitionType	La catégorie de la réquisition, telle qu'une demande de biens ou de services.
Descriptionn Cet attribut classe la réquisition en fonction de ce qui est demandé. Les types courants incluent les biens, les services ou les dépenses d'investissement. Le type peut influencer le workflow d'approbation requis et la stratégie d'approvisionnement. En analyse, le type de réquisition (Requisition Type) sert de dimension essentielle pour le filtrage et la comparaison. Par exemple, on pourrait analyser si les réquisitions de services ont un temps de cycle d'approbation plus long que les réquisitions de biens. Cela aide à comprendre si différents types de demandes présentent des comportements de processus ou des points de blocage différents. Pourquoi est-ce important ? : Permet de segmenter l'analyse pour comprendre comment le processus diffère pour divers types d'achats, tels que les biens par rapport aux services. Source des données : Ceci est souvent déterminé par le type ou la catégorie de ligne d'article sélectionné lors de la création de la réquisition. Il peut être stocké dans la table de lignes de réquisition, POR_REQUISITION_LINES_ALL. Exemples BiensServicesDépenses d'investissement

Obligatoire Recommandé Facultatif

Achats au paiement – Activités de demande d'achat

Voici les étapes et les jalons clés du processus à capturer dans votre journal d'événements pour une découverte précise du processus Achats au paiement (P2P) - Réquisition.

6 Recommandé 6 Facultatif

	Activité	Descriptionn
	Commande d'achat créée	Cet événement se produit lorsqu'une ligne de réquisition approuvée est utilisée pour générer un bon de commande. Il lie le processus de réquisition au processus d'approvisionnement en aval.
Pourquoi est-ce important ? : C'est un jalon critique pour mesurer le délai de la réquisition au bon de commande. Les retards ici indiquent des points de blocage dans le transfert de l'approbation à l'achat. Source des données : Il s'agit d'un événement explicite. Le lien entre la réquisition et le bon de commande est stocké dans des tables comme PO_LINE_LOCATIONS_ALL, qui contient une référence à l'ID de la ligne de réquisition source. Capture Trouver la date de création du Bon de commande qui fait référence à l'ID de demande donné. Type d'événement explicit
	Demande approuvée	Marque l'approbation finale de la réquisition d'achat après qu'elle a passé avec succès toutes les étapes du workflow. Ceci est déduit du statut global de la réquisition passant à 'Approuvée'.
Pourquoi est-ce important ? : C'est un jalon clé indiquant que la demande est prête pour l'action d'approvisionnement. C'est le point final pour mesurer le temps de cycle total d'approbation de la réquisition. Source des données : Déduit du changement du champ de statut du document dans la table POR_REQUISITION_HEADERS_ALL à 'APPROUVÉ'. La date de ce changement de statut est l'heure de l'événement. Capture Identifiez l'horodatage lorsque le statut du document est d'abord défini sur 'Approuvé'. Type d'événement inferred
	Demande clôturée	Indique la clôture finale du cycle de vie d'une demande, signifiant que toutes ses lignes ont été honorées (par exemple, converties en bons de commande) ou annulées. Ceci est déduit d'une mise à jour de statut final.
Pourquoi est-ce important ? : C'est l'événement de fin principal réussi pour le processus. Il confirme que la réquisition a été entièrement traitée et qu'aucune autre action n'est requise. Source des données : Déduit du changement du statut de l'en-tête de demande dans POR_REQUISITION_HEADERS_ALL à 'CLÔTURÉ'. Capture Identifiez l'horodatage lorsque le statut du document de la demande passe à 'Clôturé'. Type d'événement inferred
	Demande d'achat créée	Marque le début du processus d'approvisionnement lorsqu'un utilisateur enregistre une nouvelle réquisition d'achat pour la première fois. Cet événement est généralement capturé comme une création de dossier explicite avec un horodatage correspondant dans le système.
Pourquoi est-ce important ? : C'est l'événement de démarrage principal pour le processus de réquisition. L'analyse du temps entre la création et la soumission peut révéler des retards dans la formalisation des demandes. Source des données : Cet événement est enregistré dans la table POR_REQUISITION_HEADERS_ALL, capturé à partir de la colonne creation_date lorsqu'un nouvel ID de réquisition est généré. Capture Utilisez l'horodatage de création pour l'enregistrement de l'en-tête de la réquisition. Type d'événement explicit
	Demande rejetée	Représente le rejet final de la réquisition, mettant fin au processus pour cette demande. Ceci est déduit lorsque le statut global de la réquisition est mis à jour à 'Rejetée'.
Pourquoi est-ce important ? : Cette activité est un point final pour les demandes infructueuses. L'analyse de ces cas est indispensablele pour comprendre le KPI du taux de rejet des réquisitions et les raisons de l'échec. Source des données : Déduit du changement du statut du document dans la table POR_REQUISITION_HEADERS_ALL à 'REJETÉ'. Capture Identifiez l'horodatage lorsque le statut du document est d'abord défini sur 'Rejeté'. Type d'événement inferred
	Demande soumise	Représente l'action de l'utilisateur soumettant la réquisition terminée dans le workflow d'approbation. Ceci est capturé lorsque le statut de la réquisition passe de 'Incomplet' ou 'Brouillon' à un statut indiquant qu'elle est en attente d'approbation.
Pourquoi est-ce important ? : Cette activité déclenche le cycle d'approbation. C'est un jalon critique pour mesurer le temps de cycle d'approbation des réquisitions et les délais globaux. Source des données : Déduit d'un changement de statut dans la table POR_REQUISITION_HEADERS_ALL (par exemple, le statut passe à 'En attente d'approbation'). La date de soumission est également souvent stockée explicitement. Capture Identifiez l'horodatage lorsque le champ de statut du document passe pour la première fois à 'En attente d'approbation'. Type d'événement inferred
	Demande modifiée	Cet événement signifie qu'un utilisateur a modifié une réquisition après sa soumission initiale, nécessitant souvent le redémarrage du processus d'approbation. Ceci est déduit en détectant des changements dans les champs de données clés ou la création d'une nouvelle version de la réquisition.
Pourquoi est-ce important ? : Les modifications fréquentes indiquent des problèmes de qualité des données ou des exigences changeantes, entraînant des retravaux et des retards de processus. Cela contribue directement au le KPI 'Taux de modification des demandes'. Source des données : Déduit en suivant les numéros de version de la demande ou en identifiant les changements de statut vers 'Incomplet' après la soumission. Les journaux de modifications ou les tables de piste d'audit peuvent également capturer ces modifications. Capture Identifiez les horodatages de création de nouvelles versions pour le même ID de demande d'achat après sa soumission. Type d'événement inferred
	Demande retirée	Se produit lorsque le demandeur annule ou retire une réquisition soumise avant qu'elle n'ait été entièrement approuvée. Il s'agit généralement d'une action utilisateur explicite entraînant un changement de statut.
Pourquoi est-ce important ? : Le suivi des retraits aide à identifier les raisons d'une résiliation prématurée, telles que des besoins commerciaux modifiés ou des utilisateurs corrigeant des erreurs après la soumission. Source des données : Déduit d'un changement de statut à 'RETIRÉ' dans la table POR_REQUISITION_HEADERS_ALL. L'action est enregistrée dans l'historique des actions de la demande. Capture Détecter l'horodatage lorsque le statut de la demande est mis à jour à 'Retiré'. Type d'événement inferred
	Étape d'approbation approuvée	Représente l'action d'un approbateur individuel approuvant la réquisition à son étape désignée dans le workflow. L'événement est explicitement enregistré dans l'historique d'approbation.
Pourquoi est-ce important ? : Le suivi des étapes d'approbation individuelles aide à cartographier le chemin d'approbation réel et à mesurer le temps de traitement à chaque étape de la hiérarchie. Source des données : Capturé à partir de l'historique des actions d'approbation de la demande, qui est généralement stocké dans les tables de workflow (WF) ou de gestion du capital humain (HCM) qui gèrent les hiérarchies d'approbation. Capture Utilisez l'horodatage de l'action 'APPROUVER' du journal d'historique des actions du workflow. Type d'événement explicit
	Étape d'approbation démarrée	Marque le moment où une réquisition est assignée à un approbateur ou un groupe d'approbation spécifique au sein du workflow. Ceci est capturé à partir du journal des transactions du moteur de workflow.
Pourquoi est-ce important ? : Cette activité est indispensablele pour calculer le temps d'attente pour chaque étape d'approbation. Elle aide à identifier les points de blocage causés par des approbateurs ou des niveaux d'approbation spécifiques. Source des données : Récupéré des tables de workflow d'Oracle Fusion, qui enregistrent les tâches assignées aux utilisateurs. L'horodatage d'affectation pour la tâche d'approbation est utilisé. Capture Utilisez l'horodatage de création de la tâche dans l'historique du workflow pour la réquisition donnée. Type d'événement explicit
	Étape d'approbation rejetée	Un approbateur individuel rejette la demande, ce qui la renvoie généralement au préparateur pour correction ou met fin à la demande. Cette action est explicitement enregistrée dans l'historique du workflow.
Pourquoi est-ce important ? : Cette activité est un facteur principal de reprises et de retards. L'analyse des rejets aide à identifier les problèmes de conformité, les problèmes budgétaires ou les justifications peu claires. Source des données : Capturé à partir de l'historique des actions d'approbation de la demande. Le système de workflow enregistre une action 'REJETER' avec un horodatage. Capture Utilisez l'horodatage de l'action 'REJETER' du journal d'historique des actions du workflow. Type d'événement explicit
	Étape d'approbation retournée	Un approbateur renvoie la demande au préparateur pour des informations supplémentaires ou des corrections mineures, sans la rejeter formellement. Il s'agit généralement d'une action explicite dans le système de workflow.
Pourquoi est-ce important ? : Ceci indique un besoin de clarification et crée une boucle de reprises qui prolonge le temps de cycle. Différencier les retours des rejets offre un aperçu plus approfondi de la friction du processus. Source des données : Capturé à partir de l'historique des actions d'approbation de la demande. Le système de workflow enregistre une action 'RETOUR' ou similaire avec un horodatage. Capture Utilisez l'horodatage de l'action 'RETOUR' ou 'Demande d'informations' de l'historique du workflow. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données d'Oracle Fusion Financials

Étapes

Naviguez vers Rapports et analyses : Connectez-vous à Oracle Fusion Financials. Utilisez le menu Navigateur pour aller à Outils, puis sélectionnez Rapports et analyses. C'est le centre névralgique pour toutes les activités de reporting.
Créez une nouvelle analyse : Dans la zone de travail Rapports et analyses, cliquez sur le bouton 'Créer' et sélectionnez 'Analyse' dans le menu déroulant. Cela lancera l'éditeur d'analyse d'Oracle Transactional Business Intelligence (OTBI) dans un nouvel onglet.
Sélectionnez le domaine d'objet : Il vous sera demandé de sélectionner un domaine d'objet. Dans la zone de recherche, tapez 'Procurement - Requisitions Real Time' et sélectionnez-le dans la liste. Ce domaine d'objet contient tous les points de données nécessaires pour les événements du cycle de vie des demandes.
Construisez l'analyse pour les événements de demande d'achat : Cette étape nécessite de créer une union de plusieurs requêtes pour capturer chaque événement distinct. Étant donné que l'interface utilisateur d'OTBI ne dispose pas d'une fonctionnalité UNION ALL directe pour différents types d'événements, vous créerez un seul rapport tirant tous les champs de date et de statut pertinents. Dans l'onglet 'Critères', glissez-déposez les colonnes listées dans la section de requête depuis le panneau 'Domaines d'objet' à gauche dans la zone 'Colonnes sélectionnées'. Cela inclut les colonnes pour la date de création, la date de soumission, la date d'approbation, la date de création du bon de commande, etc.
Ajoutez l'historique des actions de demande d'achat : Pour capturer les étapes d'approbation détaillées (Approuvé, Rejeté, Retourné, Retiré), vous devez inclure des champs du dossier 'Requisition Action History' dans le domaine d'objet. Faites glisser 'Action Date', 'Action' et 'Performer' dans vos colonnes sélectionnées.
Configurez les filtres : Passez à l'onglet 'Invites' pour créer des filtres pour votre analyse. Il est indispensable de filtrer par plage de dates pour gérer le volume de données. Créez un filtre sur 'Requisition Header'.'Requisition Creation Date' et définissez-le sur une plage, par exemple, les 6 derniers mois. Vous pouvez également ajouter des invites pour 'Business Unit' ou 'Requester Name' pour affiner les données.
Exécutez et examinez le rapport : Allez à l'onglet 'Résultats' 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, contenant plusieurs colonnes de date et de statut.
Exportez les données brutes : Une fois que vous êtes satisfait de l'aperçu, cliquez sur le lien 'Export', généralement situé en bas de la page des résultats. Choisissez 'Data' > 'CSV File' comme format. Ceci téléchargera les données brutes de votre analyse.
Transformez les données au format de journal d'événements : Le fichier CSV exporté sera au format large. Vous devez utiliser un outil externe (comme un script Python, Power Query dans Excel ou un autre outil de prélèvement.paration de données) pour transformer ces données. Le processus implique de 'dépivoter' les colonnes de date en une seule colonne '(EventTime)' et de créer une colonne '(ActivityName)' correspondante pour chaque type d'événement (par exemple, 'Requisition Created', 'Requisition Submitted').
Finalisez et préparez pour le téléchargement : Après transformation, assurez-vous que le fichier contient les colonnes requises : PurchaseRequisitionId, (ActivityName), (EventTime), SourceSystem et LastDataUpdate. Enregistrez le journal d'événements final en tant que fichier CSV, qui pourra ensuite être téléchargé sur ProcessMind.

Configuration

Domaine d'objet : Le domaine d'objet principal à utiliser est 'Procurement - Requisitions Real Time'. Il contient toutes les informations d'en-tête de demande, de ligne, de répartition et d'historique d'approbation principales.
Plage de dates : Appliquez toujours un filtre de date obligatoire pour limiter le volume de données et améliorer les performances. Un filtre sur 'Requisition Header'.'Requisition Creation Date' pour les 3 à 6 derniers mois est un bon point de départ.
Filtres clés : Envisagez d'ajouter des filtres pour 'Requisition Header'.'Business Unit' et 'Requisition Header'.'Requisition Status' afin de concentrer l'extraction sur les unités organisationnelles pertinentes et d'exclure les statuts non pertinents comme 'Canceled' s'ils ne sont pas nécessaires à l'analyse.
Sélection des colonnes : Soyez sélectif avec les colonnes que vous ajoutez à l'analyse. L'inclusion de trop de colonnes, surtout provenant de nombreux dossiers (dimensions) différents, peut avoir un impact négatif sur les performances. Concentrez-vous uniquement sur les champs requis pour le journal d'événements.
Autorisations : L'utilisateur exécutant l'extraction doit avoir un rôle avec les autorisations nécessaires pour accéder à la zone de travail Rapports et analyses et au domaine d'objet 'Procurement - Requisitions Real Time'. Généralement, les rôles comme 'BI Author' ou 'Procurement Analyst' ont ces privilèges.

a Exemple de requête config

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

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Étapes

Connectez-vous à Oracle Fusion Financials avec un utilisateur disposant des privilèges BI Author ou similaires.
Naviguez vers la zone de travail Rapports et analyses en cliquant sur l'icône Navigateur, puis en sélectionnant Outils > Rapports et analyses.
Cliquez sur le bouton "Parcourir le catalogue" pour ouvrir le catalogue de Business Intelligence Publisher.
Dans l'interface BI Publisher, cliquez sur "Nouveau" et sélectionnez "Template de données" dans la liste déroulante.
Dans les propriétés du modèle de données, vous pouvez fournir un nom et une description. Cliquez sur l'icône "+" pour ajouter un nouvel ensemble de données et sélectionnez "Requête SQL".
Dans la nouvelle boîte de dialogue Jeu de données, fournissez un nom (par exemple, Requisition_Event_Log), sélectionnez la Source de données appropriée pour vos données financières (par exemple, ApplicationDB_FSCM), et définissez le Type de SQL sur "SQL standard".
Copiez le script SQL complet de la section "requête" de ce document et collez-le dans la zone de texte Requête SQL.
La requête inclut les paramètres :p_start_date et :p_end_date. Ceux-ci seront automatiquement reconnus par BI Publisher. Vous pouvez définir des valeurs par défaut si vous le souhaitez.
Enregistrez le modèle de données dans un dossier de catalogue approprié (par exemple, Shared Folders/Custom).
Pour exporter les données, retournez au catalogue, cliquez sur "Nouveau" et sélectionnez "Rapport". Liez ce nouveau rapport au modèle de données que vous venez de créer.
Exécutez le rapport, en fournissant les paramètres de date de début et de fin. Une fois que le rapport affiche les données, utilisez la fonction "Exporter" pour télécharger les résultats sous forme de fichier CSV.
Assurez-vous que le fichier CSV final est enregistré avec l'encodage UTF-8 et contient les en-têtes requis pour l'ingestion dans votre outil de process mining.

Configuration

Source de données : La source de données BI Publisher, généralement nommée 'ApplicationDB_FSCM' ou similaire, doit être configurée avec un utilisateur ayant un accès en lecture à toutes les tables de la requête, y compris celles des Achats (POR, PO), de la Gestion du Capital Humain (PER, HR) et des Finances (FUN).
Filtrage par plage de dates : La requête est conçue avec des paramètres de date obligatoires (:p_start_date et :p_end_date) qui filtrent sur la date de création de la demande. Pour les extractions initiales ou les grands systèmes, il est indispensable d'extraire les données par lots gérables, par exemple 3 à 6 mois à la fois, afin d'éviter les délais d'attente du système.
Filtrage par unité commerciale : Un filtre pour le nom de l'unité commerciale est inclus dans une section commentée de la clause WHERE de la requête. Il est fortement recommandé de décommenter et de configurer ce filtre pour limiter les données aux unités commerciales pertinentes pour votre analyse, ce qui peut améliorer considérablement les performances.
Prérequis : L'utilisateur qui crée et exécute le rapport nécessite un rôle avec des privilèges BI Publisher, tels que 'BI Administrator Role' ou 'BI Author Role'. De plus, cet utilisateur a besoin des autorisations de sécurité des données nécessaires pour accéder aux données d'achat.

a Exemple de requête sql

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Étapes

Prérequis et configuration de l'environnement : Assurez-vous 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 d'informations d'identification API (nom d'utilisateur, mot de passe) pour un utilisateur Oracle Fusion disposant d'autorisations suffisantes pour lire les données de demande d'achat, ainsi que l'URL de base de votre instance Oracle Fusion.
Enregistrez le script Python : Enregistrez le code Python complet fourni dans la section 'query' en tant que fichier, par exemple, extract_requisitions.py.
Configurez les paramètres du script : Ouvrez le fichier script dans un éditeur de texte. Modifiez les valeurs des placeholders en haut du script. Définissez FUSION_URL, USERNAME et PASSWORD pour qu'ils correspondent aux détails de votre environnement Oracle Fusion. Ajustez START_DATE et END_DATE pour définir la période d'extraction.
Comprenez les points de terminaison API et les champs : Le script cible la ressource API REST purchaseRequisitions. Il utilise le paramètre fields pour demander uniquement les données nécessaires, y compris les collections imbriquées comme lines (pour les informations de bon de commande) et actionHistory (pour les événements d'approbation), ce qui améliore les performances.
Exécutez le script : Exécutez le script depuis votre terminal en utilisant la commande : python extract_requisitions.py. Le script s'authentifiera auprès de l'API, commencera à récupérer les données et affichera les mises à jour de progression dans la console, indiquant le nombre de demandes d'achat traitées.
Gérez la pagination : Le script gère automatiquement la pagination. L'API REST d'Oracle Fusion renvoie les données par blocs (pages). Le script vérifie l'indicateur hasMore dans chaque réponse et effectue des requêtes répétées avec un paramètre offset mis à jour jusqu'à ce que toutes les demandes d'achat dans la plage de dates spécifiée aient été récupérées.
Logique de transformation des données : Pour chaque demande d'achat récupérée de l'API, le script génère plusieurs lignes dans le journal d'événements. Il crée un événement 'Demande créée' à partir de la CreationDate, un événement 'Demande soumise' à partir de la SubmittedDate, et itère à travers la collection actionHistory pour créer des événements détaillés pour chaque étape d'approbation (Démarrée, Approuvée, Rejetée, Retournée).
Déduisez les événements de statut final : Le script capture les événements de résultat final comme 'Demande approuvée' et 'Demande rejetée' en vérifiant le DocumentStatus final de la demande et en utilisant la LastUpdateDate comme horodatage de l'événement.
Générez un événement de commande d'achat : Le script inspecte chaque ligne de demande d'achat. Si une ligne a un PoHeaderId, cela signifie qu'une commande a été créée. Une entrée de journal d'événements est générée pour cette activité, liant la demande d'achat au processus d'approvisionnement en aval.
Examinez le fichier de sortie : Une fois le script terminé, il créera 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 pour le téléchargement : Ouvrez le fichier CSV généré dans un programme de tableur pour vérifier son contenu. Assurez-vous que les colonnes et les formats de données correspondent aux exigences de votre outil de process mining. Le fichier est maintenant prêt à être téléchargé sur ProcessMind.

Configuration

Informations d'identification API : Un compte utilisateur d'intégration dédié avec un rôle qui accorde un accès en lecture seule à l'API REST de Demandes d'achat est requis. Des exemples de rôles incluent le gestionnaire des achats ou un rôle d'intégration personnalisé.
Point de terminaison API REST : Le script est configuré pour utiliser le point de terminaison .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Assurez-vous que le numéro de version dans l'URL correspond à votre environnement Oracle Fusion.
Filtre de plage de dates : Le script inclut les variables START_DATE et END_DATE. Il est fortement recommandé d'extraire les données par lots gérables, par exemple 3 à 6 mois à la fois, pour éviter les dépassements de délai d'API et les problèmes de performance. Le filtre est appliqué à la CreationDate des demandes.
Sélection des champs : Le paramètre fields dans le script est impératif pour la performance. Il limite la charge utile de la réponse aux seuls attributs nécessaires pour le journal d'événements, réduisant le trafic réseau et le temps de traitement. Ne supprimez pas les champs obligatoires comme RequisitionId, CreationDate, actionHistory ou lines.
Limite de pagination : Le paramètre limit est défini sur 100, ce qui est une valeur sûre pour la plupart des environnements. Vous pouvez essayer d'augmenter cette valeur à 200 ou 500 pour une extraction potentiellement plus rapide, mais soyez conscient des problèmes de mémoire potentiels ou des limites de l'API si la valeur est trop élevée.

a Exemple de requête python

import requests
import csv
import json
from datetime import datetime

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Étapes

Naviguez vers Rapports et analyses : Connectez-vous à Oracle Fusion Financials. Utilisez le menu Navigateur pour aller à Outils, puis sélectionnez Rapports et analyses. C'est le centre névralgique pour toutes les activités de reporting.
Créez une nouvelle analyse : Dans la zone de travail Rapports et analyses, cliquez sur le bouton 'Créer' et sélectionnez 'Analyse' dans le menu déroulant. Cela lancera l'éditeur d'analyse d'Oracle Transactional Business Intelligence (OTBI) dans un nouvel onglet.
Sélectionnez le domaine d'objet : Il vous sera demandé de sélectionner un domaine d'objet. Dans la zone de recherche, tapez 'Procurement - Requisitions Real Time' et sélectionnez-le dans la liste. Ce domaine d'objet contient tous les points de données nécessaires pour les événements du cycle de vie des demandes.
Construisez l'analyse pour les événements de demande d'achat : Cette étape nécessite de créer une union de plusieurs requêtes pour capturer chaque événement distinct. Étant donné que l'interface utilisateur d'OTBI ne dispose pas d'une fonctionnalité UNION ALL directe pour différents types d'événements, vous créerez un seul rapport tirant tous les champs de date et de statut pertinents. Dans l'onglet 'Critères', glissez-déposez les colonnes listées dans la section de requête depuis le panneau 'Domaines d'objet' à gauche dans la zone 'Colonnes sélectionnées'. Cela inclut les colonnes pour la date de création, la date de soumission, la date d'approbation, la date de création du bon de commande, etc.
Ajoutez l'historique des actions de demande d'achat : Pour capturer les étapes d'approbation détaillées (Approuvé, Rejeté, Retourné, Retiré), vous devez inclure des champs du dossier 'Requisition Action History' dans le domaine d'objet. Faites glisser 'Action Date', 'Action' et 'Performer' dans vos colonnes sélectionnées.
Configurez les filtres : Passez à l'onglet 'Invites' pour créer des filtres pour votre analyse. Il est indispensable de filtrer par plage de dates pour gérer le volume de données. Créez un filtre sur 'Requisition Header'.'Requisition Creation Date' et définissez-le sur une plage, par exemple, les 6 derniers mois. Vous pouvez également ajouter des invites pour 'Business Unit' ou 'Requester Name' pour affiner les données.
Exécutez et examinez le rapport : Allez à l'onglet 'Résultats' 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, contenant plusieurs colonnes de date et de statut.
Exportez les données brutes : Une fois que vous êtes satisfait de l'aperçu, cliquez sur le lien 'Export', généralement situé en bas de la page des résultats. Choisissez 'Data' > 'CSV File' comme format. Ceci téléchargera les données brutes de votre analyse.
Transformez les données au format de journal d'événements : Le fichier CSV exporté sera au format large. Vous devez utiliser un outil externe (comme un script Python, Power Query dans Excel ou un autre outil de prélèvement.paration de données) pour transformer ces données. Le processus implique de 'dépivoter' les colonnes de date en une seule colonne '(EventTime)' et de créer une colonne '(ActivityName)' correspondante pour chaque type d'événement (par exemple, 'Requisition Created', 'Requisition Submitted').
Finalisez et préparez pour le téléchargement : Après transformation, assurez-vous que le fichier contient les colonnes requises : PurchaseRequisitionId, (ActivityName), (EventTime), SourceSystem et LastDataUpdate. Enregistrez le journal d'événements final en tant que fichier CSV, qui pourra ensuite être téléchargé sur ProcessMind.

Configuration

Domaine d'objet : Le domaine d'objet principal à utiliser est 'Procurement - Requisitions Real Time'. Il contient toutes les informations d'en-tête de demande, de ligne, de répartition et d'historique d'approbation principales.
Plage de dates : Appliquez toujours un filtre de date obligatoire pour limiter le volume de données et améliorer les performances. Un filtre sur 'Requisition Header'.'Requisition Creation Date' pour les 3 à 6 derniers mois est un bon point de départ.
Filtres clés : Envisagez d'ajouter des filtres pour 'Requisition Header'.'Business Unit' et 'Requisition Header'.'Requisition Status' afin de concentrer l'extraction sur les unités organisationnelles pertinentes et d'exclure les statuts non pertinents comme 'Canceled' s'ils ne sont pas nécessaires à l'analyse.
Sélection des colonnes : Soyez sélectif avec les colonnes que vous ajoutez à l'analyse. L'inclusion de trop de colonnes, surtout provenant de nombreux dossiers (dimensions) différents, peut avoir un impact négatif sur les performances. Concentrez-vous uniquement sur les champs requis pour le journal d'événements.
Autorisations : L'utilisateur exécutant l'extraction doit avoir un rôle avec les autorisations nécessaires pour accéder à la zone de travail Rapports et analyses et au domaine d'objet 'Procurement - Requisitions Real Time'. Généralement, les rôles comme 'BI Author' ou 'Procurement Analyst' ont ces privilèges.

a Exemple de requête config

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

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Achats au paiement : attributs de demande d'achat

Achats au paiement – Activités de demande d'achat

Guides d'extraction

Oracle Transactional Business Intelligence (OTBI) Export

Étapes

Configuration

a Exemple de requête config

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

Étapes

Configuration

a Exemple de requête sql

Script Python via l'API REST Oracle Fusion

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Réduisez de 30 % le temps du processus Demande d'achat au Paiement - Demande d'achat

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Achats au paiement : attributs de demande d'achat

Achats au paiement – Activités de demande d'achat

Guides d'extraction

Oracle Transactional Business Intelligence (OTBI) Export

Étapes

Configuration

a Exemple de requête config

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

Étapes

Configuration

a Exemple de requête sql

Script Python via l'API REST Oracle Fusion

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Réduisez de 30 % le temps du processus Demande d'achat au Paiement - Demande d'achat