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

Votre modèle de données Purchase to Pay, traitement des factures

Oracle Fusion Financials

← Retour au guide d’amélioration

Purchase to Pay - Attributs du traitement des factures (20) Purchase to Pay - Activités de traitement des factures (15) Guides d’extraction (3)

Votre modèle de données Purchase to Pay, traitement des factures

Ce modèle vous guide dans la collecte des données essentielles à l’analyse du processus Purchase to Pay, plus précisément du traitement des factures, dans Oracle Fusion Financials. Il présente les attributs essentiels et les activités clés, et explique comment extraire ces informations de votre système. Son utilisation vous aidera à préparer un journal d’événements complet et exact pour le Process Mining.

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

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

Télécharger le modèle

Purchase to Pay - Attributs du traitement des factures

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète le traitement des factures Purchase to Pay.

3 Obligatoire 7 Recommandé 10 Facultatif

	Nom	Description
	Numéro de facture InvoiceNumber	Identifiant unique d’une facture fournisseur.
Description Le numéro de facture sert d’identifiant principal du dossier. Il relie toutes les activités et tous les événements associés à une même facture fournisseur, de sa création à son paiement final. Chaque facture est traitée comme une instance de dossier unique dans l’analyse du processus. Dans le Process Mining, cet attribut est fondamental pour reconstituer le parcours de bout en bout de chaque facture. Il permet d’analyser les flux de processus, les délais de traitement et les variations facture par facture. Il constitue la clé qui relie des activités telles que la validation, l’approbation et le paiement au sein d’un processus cohérent. Pourquoi c’est important Il s’agit de l’identifiant de dossier essentiel qui relie toutes les étapes associées du processus et permet de suivre l’ensemble du cycle de vie d’une facture. Où les obtenir Se trouve généralement dans la table AP_INVOICES_ALL, dans la colonne INVOICE_NUM. Exemples INV-2023-001987654321ACME-FIN-5501
	Activité ActivityName	Nom de l’activité métier ou de l’événement survenu dans le processus de traitement de la facture.
Description Cet attribut décrit une étape précise ou un changement de statut dans le cycle de vie de la facture, par exemple « Invoice Created », « Invoice Approved » ou « Payment Executed ». Il forme la séquence d’événements qui constitue le flux du processus. L’analyse de la séquence et de la fréquence des activités est au cœur du Process Mining. Elle permet de découvrir le parcours réellement suivi, d’identifier les goulots d’étranglement lorsque certaines activités sont retardées et de repérer les écarts ou les boucles de reprise, par exemple lorsqu’une facture est rejetée après son approbation. Pourquoi c’est important Il définit les étapes du processus, ce qui est essentiel pour visualiser la cartographie du processus, analyser les variations de flux et identifier les goulots d’étranglement. Où les obtenir Cet attribut est généralement déduit d’une combinaison de champs de statut, de tables d’audit ou de journaux de flux de travail dans Oracle Fusion Financials, comme AP_INVOICES_ALL.WFAPPROVAL_STATUS ou les tables de flux de travail associées. Exemples Facture validéeBlocage appliqué à la factureFacture approuvéePaiement exécuté
	Heure de début EventTime	Horodatage indiquant le moment où une activité ou un événement s’est produit.
Description Cet attribut fournit la date et l’heure de chaque activité du processus de traitement des factures. Il est essentiel pour toutes les analyses temporelles du processus, notamment le calcul des délais de traitement, des durées et des temps d’attente entre les étapes. En classant les événements par ordre chronologique à l’aide de cet horodatage, les outils de Process Mining peuvent reconstituer la séquence exacte des activités pour chaque facture. Cela permet de calculer des indicateurs clés tels que le délai moyen du cycle de traitement des factures et d’identifier les étapes qui consomment le plus de temps. Pourquoi c’est important Cet horodatage est essentiel au calcul de tous les indicateurs de performance liés à la durée et au temps, notamment les délais de traitement et les goulots d’étranglement. Où les obtenir Cet horodatage est déduit de différents champs de date des tables Oracle Fusion, comme CREATION_DATE ou LAST_UPDATE_DATE dans des tables telles que AP_INVOICES_ALL ou les tables associées aux flux de travail et aux paiements. Exemples 2023-04-15T10:00:00Z2023-04-16T14:35:10Z2023-04-20T09:05:00Z
	Code société CompanyCode	Identifiant de l’entité juridique ou de la société qui traite la facture.
Description Le code société représente l’entité opérationnelle précise de l’organisation qui assume la responsabilité financière de la facture. Dans les organisations composées de plusieurs sociétés, il s’agit d’une donnée organisationnelle fondamentale. Cet attribut permet de segmenter l’analyse du processus par entité juridique. Il est utile pour comparer les performances du processus entre différentes parties de l’entreprise, identifier les goulots d’étranglement ou les problèmes de conformité propres à chaque entité et garantir la présentation des KPI au niveau de la société. Il intervient également souvent dans la détermination du flux de travail d’approbation approprié. Pourquoi c’est important Il permet de comparer les processus et d’évaluer la performance de différentes entités juridiques ou unités opérationnelles au sein de l’organisation. Où les obtenir Il est généralement représenté par le champ LEGAL_ENTITY_ID ou un champ similaire dans AP_INVOICES_ALL. Celui-ci peut être relié aux tables du grand livre afin d’obtenir un code ou un nom. Exemples 1001US01DE01
	Date d’échéance du paiement PaymentDueDate	Date à laquelle le paiement de la facture doit être effectué au fournisseur.
Description La date d’échéance du paiement est calculée selon les conditions de paiement convenues avec le fournisseur. Elle constitue la date limite à respecter pour éviter les pénalités, préserver de bonnes relations avec le fournisseur et bénéficier d’éventuelles remises pour paiement anticipé. Cet attribut est essentiel au Dashboard « Performance des paiements à temps » et au KPI associé. En comparant l’horodatage réel d’exécution du paiement avec la date d’échéance, l’analyse peut classer les paiements comme effectués à temps ou en retard, afin d’aider l’organisation à suivre et à améliorer la ponctualité de ses paiements. Pourquoi c’est important Il constitue la référence pour mesurer la performance des paiements à temps, un KPI important pour la gestion des fournisseurs et la santé financière. Où les obtenir Cette date est souvent disponible dans des tables de planification des paiements telles que AP_PAYMENT_SCHEDULES_ALL, associées à la facture. Exemples 2023-05-152023-06-012023-06-30
	Heure de fin EndTime	Horodatage indiquant le moment où une activité ou un événement a été terminé.
Description L’heure de fin marque l’achèvement d’une activité précise. Alors que l’heure de début indique le commencement, l’heure de fin fournit le point de clôture et permet de calculer précisément la durée de chaque étape. En analyse, la différence entre l’heure de fin et l’heure de début donne le temps de traitement de chaque activité. Elle est essentielle à l’analyse détaillée de la performance, car elle permet de distinguer le temps de traitement actif du temps d’attente. Elle permet par exemple de mesurer le temps réellement consacré par un approbateur à une tâche d’approbation, par rapport au temps pendant lequel la tâche est restée dans sa file d’attente. Pourquoi c’est important Il permet de calculer précisément les temps de traitement des activités et de distinguer le temps de travail actif du temps d’attente. Où les obtenir Il s’agit d’un attribut conceptuel dérivé de l’heure de début de l’événement suivant dans la séquence pour un dossier donné. Exemples 2023-04-15T10:05:12Z2023-04-16T15:00:00Z2023-04-20T09:15:30Z
	Montant de la facture InvoiceAmount	Valeur monétaire totale de la facture.
Description Le montant de la facture correspond à la somme totale due au fournisseur, telle qu’elle figure sur la facture. Il s’agit d’un attribut financier important qui influence l’ensemble du processus, notamment le circuit d’approbation, le niveau de contrôle et la priorité de paiement. Dans l’analyse de Process Mining, le montant de la facture constitue une dimension essentielle pour filtrer et segmenter les données. Les analystes peuvent par exemple comparer le traitement des factures de montant élevé et celui des factures de faible montant afin de déterminer si les parcours diffèrent ou si les délais de traitement varient sensiblement. Cet attribut est également indispensable au calcul des KPI financiers et à l’évaluation de l’impact financier des inefficacités du processus, comme les retards de paiement. Pourquoi c’est important Cette valeur est essentielle à l’analyse financière, à la compréhension des écarts de processus selon le montant et au calcul de KPI tels que le taux de respect des règles d’approbation. Où les obtenir Se trouve dans la table AP_INVOICES_ALL, dans la colonne INVOICE_AMOUNT. Exemples 1500.00250.75125000.50
	Nom d’utilisateur UserName	Nom de l’utilisateur qui a exécuté l’activité.
Description Cet attribut identifie l’utilisateur ou l’agent système précis responsable de l’exécution d’une activité, par exemple la validation d’une facture, l’application d’un blocage ou l’approbation d’un paiement. Il apporte une dimension humaine ou système aux Ressources du processus. L’analyse par utilisateur permet de comprendre la répartition de la charge de travail, d’identifier les personnes les plus performantes et de détecter d’éventuels besoins de formation ou problèmes de Conformité. Elle peut notamment révéler si certains utilisateurs sont régulièrement associés à des boucles de reprise ou si certaines étapes d’approbation sont toujours traitées par la même personne, ce qui crée un risque de dépendance à une ressource unique. Pourquoi c’est important Il permet d’analyser la performance des Ressources, d’équilibrer la charge de travail et d’identifier les utilisateurs ou équipes associés à certaines étapes du processus. Où les obtenir Ces informations sont souvent stockées dans des colonnes d’audit comme CREATED_BY ou LAST_UPDATED_BY dans des tables telles que AP_INVOICES_ALL, ou dans des journaux de flux de travail associés. Exemples john.doejane.smithSystem.Admin
	Nom du fournisseur VendorName	Nom du fournisseur qui a émis la facture.
Description Cet attribut identifie l’entité fournisseur à l’origine de la facture. Les informations sur le fournisseur apportent un contexte métier important à la transaction financière. L’analyse du processus par fournisseur peut révéler des informations importantes sur les relations avec les fournisseurs et leur performance. Elle peut notamment montrer si les factures de certains fournisseurs sont davantage sujettes aux écarts de rapprochement, aux blocages ou aux retards. Ces informations peuvent servir à améliorer l’intégration des fournisseurs, la communication et l’efficacité globale de la chaîne d’approvisionnement. Elles sont également utiles pour identifier d’éventuels paiements en double. Pourquoi c’est important Il permet d’analyser le processus pour chaque fournisseur et d’identifier les problèmes propres à certains fournisseurs qui entraînent des retards ou des exceptions. Où les obtenir Se trouve dans la table POZ_SUPPLIERS. La table des factures AP_INVOICES_ALL contient un VENDOR_ID qui peut être utilisé pour effectuer une jointure avec la table des fournisseurs. Exemples Acme CorporationGlobal Tech Inc.Office Supplies Co.
	Statut de la facture InvoiceStatus	Statut actuel de la facture dans son cycle de vie.
Description Cet attribut reflète le dernier état connu de la facture, par exemple « Validated », « Needs Revalidation », « Paid » ou « Canceled ». Il fournit une vue instantanée de la position de la facture dans le processus à un moment donné. Le statut de la facture est essentiel au Dashboard « Répartition des statuts actuels des factures ». Celui-ci aide les responsables des opérations à repérer les retards accumulés et à suivre l’état général du pipeline de traitement des factures. L’analyse de l’évolution des statuts dans le temps peut également fournir une vue simplifiée du flux du processus. Pourquoi c’est important Il fournit une vue de l’état actuel des factures, essentielle aux Dashboards opérationnels qui suivent les retards accumulés et la charge de travail. Où les obtenir Consultez la documentation Oracle Fusion Financials. Le statut peut être dérivé de champs tels que WFAPPROVAL_STATUS dans AP_INVOICES_ALL ou de tables associées aux approbations et aux paiements. Exemples ValidéePayéeAnnuléeNouvelle validation nécessaire
	Date de facture InvoiceDate	La date indiquée sur le document de facture du fournisseur.
Description Cet attribut correspond à la date à laquelle le fournisseur a officiellement émis la facture. Il s’agit d’une information essentielle du document source, utilisée comme point de départ pour calculer la date d’échéance du paiement selon les conditions de paiement convenues. Même si elle ne marque pas toujours le début du processus interne, la date de facture fournit un contexte essentiel. Associée au nom du fournisseur et au montant de la facture, elle permet d’identifier d’éventuelles factures en double. L’analyse du délai entre la date de facture et la date de création de la facture dans le système peut également révéler des inefficacités au niveau du courrier ou du processus d’intégration des factures. Pourquoi c’est important Il s’agit d’une donnée essentielle pour identifier les factures en double et calculer les dates d’échéance des paiements. Où les obtenir Il s’agit d’un champ standard de la table AP_INVOICES_ALL, nommé INVOICE_DATE. Exemples 2023-04-102023-05-012023-05-25
	Dernière mise à jour des données LastUpdateDate	Horodatage indiquant la dernière mise à jour de l’enregistrement dans le système source.
Description Cet attribut indique la date et l’heure de la modification la plus récente des données sous-jacentes dans Oracle Fusion Financials. Il sert à gérer les chargements incrémentiels et à maintenir le modèle de Process Mining à jour. Bien qu’il ne soit pas utilisé directement pour analyser le flux du processus, cet horodatage technique est essentiel au maintien de l’actualité et de l’intégrité des données. Il permet aux pipelines de données d’interroger efficacement uniquement les enregistrements nouveaux ou modifiés depuis la dernière mise à jour, ce qui réduit la charge sur le système source. Pourquoi c’est important Garantit l’exécution efficace et incrémentielle des pipelines de données, afin de maintenir l’analyse du processus à jour sans rechargement complet. Où les obtenir Se trouve généralement sous la forme LAST_UPDATE_DATE dans de nombreuses tables Oracle Fusion, notamment AP_INVOICES_ALL. Exemples 2023-05-20T11:00:00Z2023-05-21T16:45:00Z
	Devise InvoiceCurrencyCode	La devise du montant de la facture.
Description Cet attribut précise la devise dans laquelle la facture est libellée, par exemple USD, EUR ou GBP. Il fournit le contexte nécessaire au champ Montant de la facture. Dans une organisation internationale, l’analyse des factures par devise est importante pour le reporting financier et pour comprendre les variations du processus selon les régions. Elle garantit une interprétation correcte des montants et permet d’analyser les pratiques de paiement ou les seuils d’approbation propres à chaque devise. Pourquoi c’est important Il fournit le contexte nécessaire à l’interprétation et à l’analyse des montants financiers, en particulier dans les activités internationales. Où les obtenir Il se trouve dans la table AP_INVOICES_ALL, dans la colonne INVOICE_CURRENCY_CODE. Exemples USDEURGBPCAD
	Motif de l’écart de rapprochement MatchingDiscrepancyReason	La raison précise d’un écart entre une facture, un bon de commande et une réception.
Description Cet attribut précise pourquoi une facture a échoué lors du rapprochement automatisé. Les raisons courantes comprennent des différences de prix, de quantité ou de codes article entre la facture et le bon de commande ou le justificatif de réception correspondant. Ces informations sont essentielles pour le Dashboard « Taux d’écarts de rapprochement des factures ». En catégorisant et en analysant les motifs des écarts, les entreprises peuvent repérer les problèmes systémiques de leurs processus d’approvisionnement ou de réception. Elles peuvent ainsi mettre en œuvre des mesures correctives pour augmenter le taux de traitement des factures sans intervention manuelle, de bout en bout. Pourquoi c’est important Il explique pourquoi les factures échouent au rapprochement automatisé et fournit les analyses nécessaires pour améliorer le taux de rapprochement dès la première tentative et réduire les reprises manuelles. Où les obtenir Consultez la documentation Oracle Fusion Financials. Cette information peut être enregistrée comme un type spécifique de motif de retenue dans AP_HOLDS_ALL ou dans des tables détaillées de rapprochement associées. Exemples Le prix unitaire diffère de celui du bon de commandeQuantité facturée > quantité reçueArticle non valide sur la facture
	Motif du blocage HoldReason	La raison pour laquelle une retenue ou un blocage de paiement a été appliqué à une facture.
Description Lorsque une facture est mise en retenue, cet attribut précise la raison, par exemple « Écart de prix », « Écart de quantité » ou « Réception des marchandises en attente ». Il fournit le contexte expliquant pourquoi le flux de processus normal a été interrompu. Cet attribut constitue la dimension principale du Dashboard « Tendances et analyse des blocages de paiement ». En analysant la fréquence des différents motifs de retenue, l’entreprise peut identifier et traiter les causes profondes des blocages de paiement, notamment les problèmes liés aux processus d’approvisionnement ou à l’exactitude de la facturation des fournisseurs, et ainsi réduire les délais de traitement. Pourquoi c’est important Il fournit la cause profonde des blocages de paiement, ce qui permet de mettre en place des améliorations ciblées afin de réduire la fréquence des retenues et des retards de paiement. Où les obtenir Les informations relatives aux retenues sont généralement stockées dans la table AP_HOLDS_ALL, qui est liée à la facture et contient un motif ou un code de retenue. Exemples Écart de prixQuantité facturée supérieure à la quantité reçueNuméro de bon de commande non valide
	Nom de l’approbateur ApproverName	Nom de la personne qui a approuvé ou rejeté la facture.
Description Cet attribut enregistre l’identité de la personne qui est intervenue lors de l’étape d’approbation. Il est renseigné pour des activités telles que « Invoice Approved » ou « Invoice Rejected ». Dans l’analyse, le nom de l’approbateur sert à comprendre la charge d’approbation, à mesurer les délais de traitement de chaque approbateur et à contrôler le respect des politiques d’approbation. Pour le KPI « Taux de respect des règles d’approbation », cet attribut peut être comparé aux règles de délégation d’autorité selon le montant de la facture et le code société. Pourquoi c’est important Il est essentiel pour analyser les délais du cycle d’approbation, garantir le respect des politiques de la matrice d’approbation et comprendre la répartition de la charge de travail. Où les obtenir Ces informations se trouvent dans les tables Oracle Fusion consacrées au flux de travail ou à l’historique des approbations, associées à l’objet facture. Exemples David WilsonSarah JohnsonMichael Brown
	Numéro de bon de commande PurchaseOrderNumber	L’identifiant du bon de commande associé à la facture.
Description Cet attribut relie la facture au bon de commande correspondant, ou PO, qui a autorisé l’achat des biens ou services. Les factures peuvent être associées à un PO ou ne pas l’être. L’analyse par PO établit un lien avec la partie approvisionnement du processus P2P. Elle aide à évaluer le niveau de conformité du processus d’approvisionnement et à déterminer si les problèmes de facturation, tels que les écarts de rapprochement, trouvent leur origine dans des problèmes liés au PO initial. La présence ou l’absence d’un numéro de PO constitue un moyen essentiel de segmenter et d’analyser les différents parcours de traitement des factures. Pourquoi c’est important Il relie la facture au processus d’approvisionnement et constitue un attribut essentiel pour analyser les flux de factures avec PO et sans PO. Où les obtenir Ces informations sont disponibles en reliant les lignes de facture de AP_INVOICE_LINES_ALL aux répartitions du PO via PO_DISTRIBUTION_ID. Exemples PO-2023-5001600789PO-FIN-9981
	Paiement effectué à temps IsOnTimePayment	Indicateur booléen précisant si la facture a été payée à sa date d’échéance.
Description Cet indicateur prend la valeur true si le paiement a été exécuté à la date d’échéance du paiement ou avant celle-ci, et false dans le cas contraire. Il fournit une classification simple et claire pour chaque facture payée. Cet attribut calculé alimente directement le KPI Taux de paiement à temps et le Dashboard associé. Il simplifie l’analyse en permettant de filtrer, de compter et de visualiser facilement la proportion de paiements en retard et de paiements effectués à temps, sans devoir comparer les dates à la volée. Il aide ainsi à mesurer rapidement l’ampleur des retards de paiement et à suivre les progrès au fil du temps. Pourquoi c’est important Il simplifie l’analyse du respect des délais de paiement et constitue la donnée directement utilisée pour calculer le KPI Taux de paiement à temps. Où les obtenir Il s’agit d’un attribut calculé, obtenu en comparant l’horodatage de l’activité « Payment Executed » avec l’attribut « PaymentDueDate ». Exemples truefalse
	Reprise IsRework	Indicateur booléen identifiant les activités qui font partie d’une boucle de reprise.
Description Cet indicateur prend la valeur true pour les activités qui signalent un écart par rapport au flux de processus idéal, telles que « Invoice Corrected » ou une seconde occurrence de « Invoice Validated » après un rejet. Il permet d’identifier et de quantifier explicitement les boucles de processus inefficaces. Cet attribut est essentiel pour le Dashboard « Taux de reprises et de gestion des exceptions ». En signalant les activités de reprise, les analystes peuvent quantifier facilement le volume et le coût des reprises, en identifier les causes profondes et mesurer l’impact des initiatives d’amélioration visant à obtenir un résultat correct dès la première tentative. Pourquoi c’est important Il identifie et quantifie explicitement les reprises, ce qui facilite l’analyse de leur fréquence, de leurs causes et de leur impact sur les inefficacités du processus. Où les obtenir Il s’agit d’un attribut calculé. La logique est définie lors de la transformation des données afin d’identifier les séquences d’activités qui constituent une reprise. Exemples truefalse
	Système source SourceSystem	Identifie le système d’origine dans lequel les données de l’événement ont été enregistrées.
Description Cet attribut précise l’application ou le module source qui a généré les données, par exemple Oracle Fusion Financials. Dans les environnements intégrant plusieurs systèmes, ce champ permet de distinguer l’origine des différentes étapes du processus. La connaissance du système source est utile pour valider les données, résoudre les problèmes et analyser les variations du processus propres à un système donné. Elle apporte de la clarté dans les environnements informatiques complexes où le parcours d’une facture peut s’étendre sur plusieurs applications. Pourquoi c’est important Il fournit le contexte sur l’origine des données, ce qui est important pour la gouvernance des données, la résolution des problèmes et l’analyse du comportement du processus propre à chaque système. Où les obtenir Il s’agit souvent d’une valeur statique ajoutée lors de l’extraction des données pour indiquer l’origine du jeu de données. Exemples Oracle Fusion FinancialsOracle Payables Cloud

Obligatoire Recommandé Facultatif

Purchase to Pay - Activités de traitement des factures

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

6 Recommandé 9 Facultatif

	Activité	Description
	Facture approuvée	La facture a été entièrement approuvée par toutes les parties requises dans le flux de travail. Elle est désormais prête pour la comptabilisation et la planification du paiement.
Pourquoi c’est important Cette étape importante confirme la réussite du processus d’approbation. Les délais qui la précèdent constituent souvent des goulots d’étranglement. Où les obtenir Déduit du changement de APPROVAL_STATUS dans la table AP_INVOICES_ALL vers un état final approuvé tel que « Approved » ou « flux de travail approuvé ». L’historique d’audit de ce champ fournit l’horodatage. Collecte Déduit du changement de AP_INVOICES_ALL.APPROVAL_STATUS à « Approved ». Type d’événement inferred
	Facture comptabilisée	La facture est correctement enregistrée dans le grand livre, ce qui crée les écritures comptables. Cet événement confirme que l’impact financier de la facture a été officiellement enregistré.
Pourquoi c’est important Il s’agit d’un point de contrôle financier important et d’un préalable au paiement. Il confirme que la facture est entièrement validée et approuvée, et qu’elle est prête à être réglée. Où les obtenir Déduit du statut dans la table AP_INVOICE_DISTRIBUTIONS_ALL (ACCRUAL_POSTED_FLAG = « Y ») ou de la présence d’écritures correspondantes dans les tables du grand livre, telles que XLA_AE_HEADERS. Collecte Déduit des indicateurs présents dans AP_INVOICE_DISTRIBUTIONS_ALL ou des écritures associées du grand livre. Type d’événement inferred
	Facture créée	Représente la création initiale d’un enregistrement de facture dans le système, par saisie manuelle, numérisation ou transmission électronique. Cet événement est généralement enregistré lorsqu’une nouvelle ligne est insérée dans la table principale des factures.
Pourquoi c’est important Marque le début du cycle de traitement de la facture. L’analyse du délai à partir de cet événement permet d’évaluer l’efficacité de la saisie des données et les retards au démarrage du processus. Où les obtenir Dans Oracle Fusion Financials, cela correspond à l’horodatage de création de l’enregistrement dans la table AP_INVOICES_ALL, plus précisément dans la colonne CREATION_DATE. Collecte Horodatage de création de l’enregistrement dans AP_INVOICES_ALL. Type d’événement explicit
	Facture envoyée pour approbation	La facture est soumise à un flux de travail d’approbation conformément aux règles métier configurées. Cette étape marque le début du cycle formel d’approbation.
Pourquoi c’est important Cette étape lance une partie importante du processus. Le suivi de son heure de début est essentiel pour mesurer et optimiser le « Délai du cycle d’approbation des factures ». Où les obtenir Déduit d’un changement de statut dans la table AP_INVOICES_ALL, lorsque APPROVAL_STATUS passe à un état tel que « Initiated » ou « Pending Approval ». Les tables des flux de travail peuvent également contenir cet événement. Collecte Déduit du changement de AP_INVOICES_ALL.APPROVAL_STATUS à « Initiated ». Type d’événement inferred
	Facture rapprochée avec le bon de commande	Cette activité indique le rapprochement réussi d’une ligne de facture avec la ligne correspondante d’un bon de commande, confirmant que les biens ou services facturés ont bien été commandés. Il s’agit généralement d’une action automatisée ou manuelle enregistrée dans le système.
Pourquoi c’est important Cette étape est essentielle au rapprochement à trois niveaux, qui porte sur le bon de commande, la réception et la facture. Les échecs à ce stade constituent une source majeure d’exceptions et de retards. Où les obtenir Peut être déduit de la création d’enregistrements dans la table AP_INVOICE_DISTRIBUTIONS_ALL reliant la facture à une distribution de bon de commande (PO_DISTRIBUTION_ID). Le statut de rapprochement au niveau de la ligne dans AP_INVOICE_LINES_ALL peut également être utilisé. Collecte Déduit du renseignement des données de distribution du bon de commande sur les lignes de facture. Type d’événement inferred
	Paiement exécuté	Confirmation finale indiquant que le paiement a été effectué et compensé. Pour un chèque, il s’agit de la date de compensation ; pour un paiement électronique, il s’agit de la confirmation de la banque.
Pourquoi c’est important Il s’agit de la dernière activité du cycle de vie de la facture, qui marque la réussite du processus. Elle constitue le point final pour calculer le « Délai moyen du cycle de traitement des factures » et le « Taux de paiement à temps ». Où les obtenir Déduit du passage du statut du paiement à « Cleared » ou « Reconciled » dans la table AP_CHECKS_ALL, à l’aide de CLEARED_DATE, ou des données de rapprochement bancaire du module Cash Management (CE_STATEMENT_LINES). Collecte Déduit des mises à jour de statut dans AP_CHECKS_ALL ou du rapprochement dans le module CE. Type d’événement inferred
	Blocage appliqué à la facture	Activité générique représentant l’application d’un blocage à une facture, l’empêchant de passer au paiement. Les raisons peuvent être diverses : problème de rapprochement, fonds insuffisants ou intervention manuelle.
Pourquoi c’est important Cette étape a un impact direct sur le délai de traitement et peut entraîner des retards de paiement. L’analyse des blocages est essentielle pour identifier et résoudre les problèmes systémiques du processus, notamment dans le cadre de l’analyse « Tendances des blocages de paiement ». Où les obtenir Enregistré explicitement dans la table AP_HOLDS_ALL. Chaque ligne représente un blocage avec une date de création (HOLD_DATE) et un motif. Collecte Création d’un enregistrement dans la table AP_HOLDS_ALL. Type d’événement explicit
	Blocage levé sur la facture	Cet événement marque la résolution d’un blocage précédemment appliqué à la facture. Un utilisateur ou un processus automatisé intervient pour supprimer le blocage et permettre à la facture de poursuivre son cycle de traitement.
Pourquoi c’est important Le délai entre l’application et la levée d’un blocage constitue une mesure importante de l’efficacité de la gestion des exceptions. Il alimente le KPI « Délai moyen de résolution des exceptions ». Où les obtenir Enregistré dans la table AP_HOLDS_ALL. Lorsqu’un blocage est levé, les champs RELEASE_LOOKUP_CODE et RELEASE_REASON sont renseignés, ainsi que LAST_UPDATE_DATE. Collecte Mise à jour d’un enregistrement dans la table AP_HOLDS_ALL indiquant que le blocage a été levé. Type d’événement explicit
	Écart de rapprochement identifié	Se produit lorsque le système ou un utilisateur identifie une différence entre les informations de la facture, du bon de commande et de la réception, par exemple au niveau du prix ou de la quantité. Cela entraîne souvent le placement automatique d’un blocage sur la facture.
Pourquoi c’est important Met en évidence les exceptions du processus qui nécessitent une intervention manuelle. Le suivi de ces événements est essentiel pour le KPI « Taux d’écarts de rapprochement des factures » et l’analyse des causes profondes. Où les obtenir Cet événement est souvent enregistré sous la forme d’un type précis de blocage appliqué à la facture. Consultez la table AP_HOLDS_ALL pour rechercher les types de blocage liés au rapprochement, par exemple « QTY REC » ou « PRICE ». HOLD_DATE indique l’horodatage. Collecte Création d’un enregistrement dans AP_HOLDS_ALL avec un type de blocage lié au rapprochement. Type d’événement explicit
	Facture annulée	La facture a été annulée ou invalidée et ne sera plus traitée ni payée. Il s’agit d’un état final du processus.
Pourquoi c’est important Il s’agit d’un point final important pour les factures qui n’aboutissent pas à un paiement. L’analyse des annulations peut révéler des problèmes liés aux doublons ou à des soumissions incorrectes de la part des fournisseurs. Où les obtenir Déduit d’un changement de statut dans AP_INVOICES_ALL. La colonne CANCELLED_DATE est renseignée avec l’horodatage de l’annulation. Collecte Le champ CANCELLED_DATE de la table AP_INVOICES_ALL est renseigné. Type d’événement explicit
	Facture corrigée	Se produit lorsqu’un utilisateur modifie une facture, souvent à la suite d’un rejet ou pour corriger une erreur de saisie. Cette étape correspond à une reprise manuelle dans le processus.
Pourquoi c’est important Cette activité constitue un indicateur clair de reprise. L’analyse de sa fréquence permet de quantifier les inefficacités du processus et alimente le KPI « Taux de reprise des factures ». Où les obtenir Peut être déduit du suivi des mises à jour importantes de l’enregistrement de facture dans AP_INVOICES_ALL, après sa validation ou sa soumission pour approbation. L’horodatage LAST_UPDATE_DATE ainsi que les données de la piste d’audit sont nécessaires. Collecte Déduit de la comparaison de LAST_UPDATE_DATE après un rejet ou un blocage. Type d’événement inferred
	Facture rejetée	Un approbateur a rejeté la facture pendant le flux de travail d’approbation. Cette action renvoie généralement la facture pour correction ou annulation et déclenche une boucle de reprise.
Pourquoi c’est important Représente un résultat défavorable et une cause importante de reprises et d’allongement des délais de traitement. Le suivi des rejets permet d’identifier les problèmes de qualité des factures ou de respect des bons de commande. Où les obtenir Déduit du changement de APPROVAL_STATUS dans la table AP_INVOICES_ALL vers « Rejected ». L’historique du flux de travail contient les informations sur l’auteur et la date du rejet. Collecte Déduit du changement de AP_INVOICES_ALL.APPROVAL_STATUS à « Rejected ». Type d’événement inferred
	Facture validée	Indique que la facture a passé les contrôles de validation du système concernant l’exhaustivité et l’exactitude des informations d’en-tête et de ligne. Cet événement est souvent déduit d’un changement de statut de l’enregistrement de facture.
Pourquoi c’est important Il s’agit d’une étape importante avant le rapprochement et l’approbation. Les retards à ce stade peuvent révéler des problèmes de qualité des données de facture ou de configuration du système. Où les obtenir Déduit du passage du statut de la facture à « Validated » dans la table AP_INVOICES_ALL. L’historique des modifications ou la piste d’audit de la colonne VALIDATION_STATUS peut être utilisé. Collecte Déduit d’une modification du champ AP_INVOICES_ALL.VALIDATION_STATUS. Type d’événement inferred
	Paiement créé	L’instruction de paiement de la facture a été générée par le système. Il peut s’agir de la création d’un chèque, d’un fichier de transfert électronique de fonds (EFT) ou d’un autre instrument de paiement.
Pourquoi c’est important C’est à ce stade que l’organisation engage les fonds destinés au paiement. Il s’agit d’une étape importante juste avant la sortie des fonds du compte bancaire. Où les obtenir Enregistré dans la table AP_CHECKS_ALL, qui contient les informations relatives à tous les paiements. CHECK_DATE indique la date de création du document de paiement. Collecte Création d’un enregistrement dans la table AP_CHECKS_ALL. Type d’événement explicit
	Paiement planifié	La facture est sélectionnée et incluse dans une demande de traitement des paiements, souvent appelée cycle ou lot de paiements. Elle est désormais mise en file d’attente pour paiement.
Pourquoi c’est important Cette étape se situe entre la comptabilisation et le paiement effectif. Sa durée influe sur les prévisions de trésorerie et sur la possibilité de bénéficier de remises pour paiement anticipé. Où les obtenir Cet événement est enregistré dans la table AP_INVOICE_PAYMENTS_ALL lorsqu’un enregistrement de paiement est créé, mais avant la confirmation du paiement. Il peut également être présent dans des tables de lots de paiements telles que IBY_PAYMENT_PROCESS_REQUESTS. Collecte Création d’un enregistrement dans AP_INVOICE_PAYMENTS_ALL pour un paiement planifié. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

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

Étapes

Connectez-vous à Oracle Fusion Cloud : accédez à votre environnement Oracle Fusion Cloud avec un utilisateur disposant du rôle BI Cloud Connector Administrator (BICC_ADMIN).
Accédez à BI Cloud Connector : dans le menu de navigation principal, sélectionnez Tools > BI Cloud Connector. La console BICC s’ouvre.
Sélectionnez l’offre : dans la console BICC, choisissez l’offre correspondant à vos données Financials. Elle est généralement nommée « Financials ».
Configurez le stockage externe : accédez à la section « Configure External Storage ». Configurez la connexion vers votre stockage cloud, où les fichiers CSV extraits seront déposés, par exemple Oracle Cloud Infrastructure (OCI) Object Storage.
Activez les offres à extraire : accédez à la section « Manage Offerings and PVOs » ou à une section équivalente. Sélectionnez l’offre « Financials » et activez-la pour l’extraction.
Sélectionnez les Public View Objects (PVOs) : recherchez et sélectionnez les PVOs nécessaires au processus de facturation. Les principaux PVOs sont : FscmTopModelAM.FinApInvQuickInvoicesAM.InvoiceHeaderPVO, FscmTopModelAM.FinApInvHoldAM.InvoiceHoldPVO, FscmTopModelAM.FinApInvSharedAM.InvoiceApprovalHistoryPVO et FscmTopModelAM.FinApPmtsInvPmtsAM.PaymentPVO.
Planifiez le travail d’extraction : accédez à « Manage Extract Schedules ». Créez un nouveau travail, attribuez-lui un nom explicite et sélectionnez tous les PVOs activés à l’étape précédente. Planifiez son exécution. Pour le chargement initial, exécutez-le sur la période historique souhaitée. Pour les exécutions suivantes, configurez des extractions incrémentielles basées sur LastUpdateDate.
Suivez et récupérez les données : surveillez l’avancement du travail dans la console BICC. Une fois l’exécution terminée, accédez à l’emplacement de stockage cloud configuré. Les données extraites se présentent sous la forme d’un ensemble de fichiers CSV compressés, un par PVO.
Chargez les données dans une zone de préparation : décompressez les fichiers et chargez les CSV dans une base de données de préparation ou une plateforme de traitement des données, telle qu’un entrepôt de données ou un lac de données, où vous pourrez exécuter des requêtes SQL. Chaque fichier CSV doit être chargé dans sa propre table.
Transformez les données en Event Log : exécutez la requête SQL fournie sur les tables de votre zone de préparation. Cette requête regroupe les données des différentes tables afin de créer une table d’Event Log unique et unifiée.
Exportez les données pour ProcessMind : exportez le résultat de la requête SQL dans un fichier CSV unique. Vérifiez que les en-têtes de colonnes correspondent aux attributs requis (InvoiceNumber, ActivityName, EventTime, etc.) pour le chargement dans l’application ProcessMind.

Configuration

Principaux objets de vue publique (PVO) : l’extraction repose sur plusieurs PVO essentiels de l’offre Financials. Vous devez au minimum inclure :
- FscmTopModelAM.FinApInvQuickInvoicesAM.InvoiceHeaderPVO : pour les données principales des factures ainsi que les événements de création, de validation et d’annulation.
- FscmTopModelAM.FinApInvHoldAM.InvoiceHoldPVO : pour tous les événements de mise en attente et de libération des factures.
- FscmTopModelAM.FinApInvSharedAM.InvoiceApprovalHistoryPVO : pour enregistrer les étapes détaillées du flux de travail d’approbation, comme la soumission, l’approbation et le rejet.
- FscmTopModelAM.FinApPmtsInvPmtsAM.PaymentPVO : pour les événements de création et d’exécution des paiements.
- FscmTopModelAM.FinApInvPmtsAM.InstallmentPVO : pour identifier le moment où une facture est planifiée pour paiement.
Extractions incrémentielles : pour assurer un suivi continu, configurez la tâche BICC afin qu’elle réalise des extractions incrémentielles. Utilisez la colonne LastUpdateDate, disponible dans la plupart des PVO, comme critère de filtrage afin d’extraire uniquement les enregistrements nouveaux ou modifiés depuis la dernière exécution.
Filtrage par période : lors du premier chargement des données historiques, il est recommandé d’extraire une période gérable, par exemple les données des 6 à 12 derniers mois. Vous pouvez appliquer un filtre global dans la planification de la tâche BICC afin de limiter l’extraction à une période précise.
Filtre par unité opérationnelle : pour limiter le périmètre de l’extraction, appliquez un filtre sur BusinessUnitName ou sur un attribut similaire dans la configuration de la tâche BICC. Cette étape est essentielle dans les environnements comprenant plusieurs entités afin de maîtriser le volume de données.
Prérequis : votre compte utilisateur doit disposer des rôles appropriés, principalement BICC Administrator (BICC_ADMIN) et Functional Setup User (FSM_IMPLEMENTATION_CONSULTANT), pour configurer et exécuter les tâches d’extraction. Vous devez également disposer d’un emplacement de stockage cloud configuré et accessible, comme OCI Object Storage ou UCM.

a Exemple de requête sql

-- This script is designed to be run on the CSV files after they have been extracted by BICC and loaded into a staging database.
-- Each CTE (e.g., Invoices, Holds) represents a table created from a corresponding PVO's CSV file.

WITH Invoices AS (
    SELECT 
        InvoiceId,
        InvoiceNumber,
        InvoiceAmount,
        SupplierName AS VendorName,
        CreationDate,
        CreatedBy AS UserName, 
        LastUpdateDate, 
        LastUpdatedBy, 
        ValidatedDate,
        ApprovalStatus,
        WfApprovalStatus,
        PayablesAccountingStatus,
        CancelledDate,
        CancelledBy,
        BusinessUnitName AS CompanyCode
    FROM FscmTopModelAM_FinApInvQuickInvoicesAM_InvoiceHeaderPVO
    WHERE LastUpdateDate >= '[Specify Start Date]'
),
Holds AS (
    SELECT 
        InvoiceId,
        HoldDate,
        ReleasedDate,
        HoldReason,
        CreatedBy,
        LastUpdatedBy
    FROM FscmTopModelAM_FinApInvHoldAM_InvoiceHoldPVO
),
ApprovalHistory AS (
    SELECT
        InvoiceId,
        ActionDate,
        Action,
        Performer AS UserName
    FROM FscmTopModelAM_FinApInvSharedAM_InvoiceApprovalHistoryPVO
),
Installments AS (
    SELECT 
        InvoiceId,
        DueDate AS PaymentDueDate,
        PaymentStatusFlag,
        LastUpdateDate
    FROM FscmTopModelAM_FinApInvPmtsAM_InstallmentPVO
),
Payments AS (
    SELECT
        InvoiceId,
        PaymentId,
        CreationDate,
        CreatedBy AS UserName,
        PaymentDate
    FROM FscmTopModelAM_FinApPmtsInvPmtsAM_PaymentPVO
)

-- 1. Invoice Created
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Created' AS "ActivityName",
    i.CreationDate AS "EventTime",
    i.CreationDate AS "EndTime",
    i.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    i.ApprovalStatus AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId

UNION ALL

-- 2. Invoice Validated
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Validated' AS "ActivityName",
    i.ValidatedDate AS "EventTime",
    i.ValidatedDate AS "EndTime",
    i.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Validated' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE i.ValidatedDate IS NOT NULL

UNION ALL

-- 3. Invoice Matched to PO (Inferred from hold release)
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Matched to PO' AS "ActivityName",
    h.ReleasedDate AS "EventTime",
    h.ReleasedDate AS "EndTime",
    h.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    i.ApprovalStatus AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Holds h ON i.InvoiceId = h.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE h.HoldReason IN ('QTY ORD', 'AMT ORD', 'PRICE') AND h.ReleasedDate IS NOT NULL

UNION ALL

-- 4. Matching Discrepancy Identified
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Matching Discrepancy Identified' AS "ActivityName",
    h.HoldDate AS "EventTime",
    h.HoldDate AS "EndTime",
    h.CreatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'On Hold' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Holds h ON i.InvoiceId = h.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE h.HoldReason IN ('QTY ORD', 'AMT ORD', 'PRICE')

UNION ALL

-- 5. Hold Placed on Invoice
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Hold Placed on Invoice' AS "ActivityName",
    h.HoldDate AS "EventTime",
    h.HoldDate AS "EndTime",
    h.CreatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'On Hold' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Holds h ON i.InvoiceId = h.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId

UNION ALL

-- 6. Hold Released from Invoice
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Hold Released from Invoice' AS "ActivityName",
    h.ReleasedDate AS "EventTime",
    h.ReleasedDate AS "EndTime",
    h.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    i.ApprovalStatus AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Holds h ON i.InvoiceId = h.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE h.ReleasedDate IS NOT NULL

UNION ALL

-- 7. Invoice Sent for Approval
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Sent for Approval' AS "ActivityName",
    ah.ActionDate AS "EventTime",
    ah.ActionDate AS "EndTime",
    ah.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Initiated' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN ApprovalHistory ah ON i.InvoiceId = ah.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE ah.Action = 'SUBMITTED'

UNION ALL

-- 8. Invoice Approved
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Approved' AS "ActivityName",
    ah.ActionDate AS "EventTime",
    ah.ActionDate AS "EndTime",
    ah.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Workflow approved' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN ApprovalHistory ah ON i.InvoiceId = ah.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE ah.Action = 'APPROVED'

UNION ALL

-- 9. Invoice Rejected
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Rejected' AS "ActivityName",
    ah.ActionDate AS "EventTime",
    ah.ActionDate AS "EndTime",
    ah.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Rejected' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN ApprovalHistory ah ON i.InvoiceId = ah.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE ah.Action = 'REJECTED'

UNION ALL

-- 10. Invoice Corrected (Inferred from update after rejection)
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Corrected' AS "ActivityName",
    i.LastUpdateDate AS "EventTime",
    i.LastUpdateDate AS "EndTime",
    i.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    i.ApprovalStatus AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE i.WfApprovalStatus = 'WORKFLOW_REJECTED' AND i.LastUpdatedBy <> 'FUSION_APPS_PRC_SOA_APPID'

UNION ALL

-- 11. Invoice Accounted
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Accounted' AS "ActivityName",
    i.LastUpdateDate AS "EventTime",
    i.LastUpdateDate AS "EndTime",
    i.LastUpdatedBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Accounted' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE i.PayablesAccountingStatus = 'ACCOUNTED'

UNION ALL

-- 12. Payment Scheduled
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    inst.LastUpdateDate AS "EventTime",
    inst.LastUpdateDate AS "EndTime",
    i.LastUpdatedBy AS "UserName", -- User who ran the PPR is not in this PVO
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Selected for Payment' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE inst.PaymentStatusFlag = 'Y'

UNION ALL

-- 13. Payment Created
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Payment Created' AS "ActivityName",
    p.CreationDate AS "EventTime",
    p.CreationDate AS "EndTime",
    p.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Paid' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Payments p ON i.InvoiceId = p.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId

UNION ALL

-- 14. Payment Executed
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    p.PaymentDate AS "EventTime",
    p.PaymentDate AS "EndTime",
    p.UserName AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Paid' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
JOIN Payments p ON i.InvoiceId = p.InvoiceId
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE p.PaymentDate IS NOT NULL

UNION ALL

-- 15. Invoice Canceled
SELECT
    i.InvoiceNumber AS "InvoiceNumber",
    'Invoice Canceled' AS "ActivityName",
    i.CancelledDate AS "EventTime",
    i.CancelledDate AS "EndTime",
    i.CancelledBy AS "UserName",
    i.InvoiceAmount AS "InvoiceAmount",
    i.VendorName AS "VendorName",
    inst.PaymentDueDate AS "PaymentDueDate",
    'Cancelled' AS "InvoiceStatus",
    i.CompanyCode AS "CompanyCode"
FROM Invoices i
LEFT JOIN Installments inst ON i.InvoiceId = inst.InvoiceId
WHERE i.CancelledDate IS NOT NULL;

Étapes

Accédez à Oracle BI Publisher : connectez-vous à Oracle Fusion Applications avec un utilisateur disposant du rôle BI Administrator ou d’un rôle équivalent. Accédez à l’outil Reports and Analytics en ouvrant le menu Navigator, puis en sélectionnant Tools et enfin Reports and Analytics.
Accédez au catalogue : dans l’espace de travail Reports and Analytics, cliquez sur le bouton Browse Catalog pour ouvrir l’interface Oracle BI Publisher.
Créez un modèle de données : dans le catalogue BI Publisher, accédez à un dossier approprié, par exemple Shared Folders > Custom. Cliquez sur le menu déroulant New et sélectionnez Data Model.
Définissez le jeu de données de la requête SQL : dans l’éditeur Data Model, cliquez sur l’icône « + » pour ajouter un jeu de données, puis sélectionnez SQL Query dans la liste.
Configurez le jeu de données : dans la boîte de dialogue New Data Set, saisissez un nom tel que P2P_Invoice_Events. Sélectionnez la source de données appropriée, généralement ApplicationDB_FSCM pour les données financières. Vérifiez que le type de SQL est défini sur Standard SQL.
Saisissez la requête SQL : copiez la requête SQL complète fournie dans la section query de ce document et collez-la dans la zone de texte SQL Query.
Définissez les paramètres : la requête utilise des paramètres de filtrage. Dans les propriétés du modèle de données, créez trois paramètres : p_start_date, p_end_date et p_bu_name. Définissez leur type de données sur String. L’utilisateur saisira leurs valeurs lors de l’exécution du rapport, par exemple « 2023-01-01 » pour les dates et le nom de l’unité opérationnelle concernée.
Enregistrez le modèle de données : enregistrez le modèle de données dans votre dossier personnalisé. Vous pouvez afficher des données d’exemple en cliquant sur l’onglet « Data » et en renseignant les valeurs des paramètres créés.
Créez un rapport : revenez au catalogue, cliquez sur le menu déroulant New et sélectionnez Report. Dans l’assistant de création du rapport, sélectionnez l’option « Use Data Model » et recherchez le modèle de données que vous venez d’enregistrer.
Configurez la mise en page et le format de sortie : dans l’éditeur de rapport, une mise en page sous forme de tableau simple suffit. L’étape la plus importante consiste à configurer le format de sortie par défaut. Cliquez sur « View a List » et vérifiez que CSV est le format par défaut et le seul format activé. Vous obtiendrez ainsi un fichier de données propre, sans mise en forme.
Planifiez le rapport : enregistrez le rapport. Vous pouvez désormais l’exécuter à la demande ou, pour de meilleures performances, planifier son exécution en dehors des heures de pointe. La planification peut être configurée pour déposer le fichier CSV dans une destination précise, telle que le serveur Universal Content Management (UCM), depuis lequel il pourra être récupéré pour être chargé.
Exportez et préparez les données : une fois le travail du rapport terminé, téléchargez le fichier CSV obtenu. Vérifiez que les en-têtes de colonnes correspondent aux attributs requis (InvoiceNumber, ActivityName, EventTime, etc.) avant de le charger dans l’outil de Process Mining.

Configuration

Source de données : la requête doit être exécutée sur la base de données de l’application Fusion Financials, généralement connectée via la source de données JNDI ApplicationDB_FSCM dans BI Publisher.
Paramètres : le modèle de données doit être configuré avec les paramètres suivants afin de permettre une extraction flexible :
- p_start_date : date de début de la période d’extraction au format « YYYY-MM-DD ».
- p_end_date : date de fin de la période d’extraction au format « YYYY-MM-DD ».
- p_bu_name : nom de l’unité opérationnelle, ou Company Code, utilisée pour filtrer les données. Utilisez un caractère générique tel que « % » pour extraire les données de toutes les unités opérationnelles.
Période : pour l’extraction initiale, il est recommandé d’utiliser une période de 3 à 6 mois. Cela permet de disposer d’un échantillon représentatif tout en maîtrisant les performances de l’extraction.
Performances : l’extraction de données sur de longues périodes ou pour toutes les unités opérationnelles en une seule fois peut mobiliser beaucoup de ressources et entraîner des délais d’expiration. Il est recommandé d’exécuter les extractions volumineuses par lots plus petits et successifs, par exemple mois par mois, ou de les planifier en dehors des heures de pointe.
Prérequis : l’utilisateur qui crée et exécute le rapport doit disposer d’un rôle autorisant l’accès à l’outil BI Publisher, par exemple BI Administrator, ainsi que des privilèges de sécurité nécessaires pour consulter les tables sous-jacentes des comptes fournisseurs (AP_INVOICES_ALL, AP_PAYMENTS_ALL, etc.) pour les unités opérationnelles concernées.

a Exemple de requête sql

WITH INVOICE_BASE AS (
    SELECT 
        AIA.INVOICE_ID,
        AIA.INVOICE_NUM,
        AIA.INVOICE_AMOUNT,
        AIA.CREATION_DATE,
        AIA.CREATED_BY,
        AIA.LAST_UPDATE_DATE,
        AIA.LAST_UPDATED_BY,
        AIA.CANCELLED_DATE,
        AIA.CANCELLED_BY,
        AIA.WFAPPROVAL_STATUS,
        AIA.TERMS_DATE AS PAYMENT_DUE_DATE,
        PSV.VENDOR_NAME,
        FABUV.BU_NAME AS COMPANY_CODE
    FROM 
        AP_INVOICES_ALL AIA
    JOIN 
        POZ_SUPPLIERS_V PSV ON AIA.VENDOR_ID = PSV.VENDOR_ID
    JOIN
        FUN_ALL_BUSINESS_UNITS_V FABUV ON AIA.ORG_ID = FABUV.BU_ID
    WHERE 
        AIA.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
        AND FABUV.BU_NAME LIKE :p_bu_name
)
-- 1. Invoice Created
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Created' AS "ActivityName",
    CAST(IB.CREATION_DATE AS TIMESTAMP) AS "EventTime",
    CAST(IB.CREATION_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = IB.CREATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    INVOICE_BASE IB

UNION ALL

-- 2. Invoice Validated
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Validated' AS "ActivityName",
    CAST(AIA.LAST_UPDATE_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AIA.LAST_UPDATE_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AIA.LAST_UPDATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    AIA.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_INVOICES_ALL AIA
JOIN 
    INVOICE_BASE IB ON AIA.INVOICE_ID = IB.INVOICE_ID
WHERE 
    AIA.WFAPPROVAL_STATUS IN ('VALIDATED', 'NEEDS REVALIDATION', 'STOPPED')

UNION ALL

-- 3. Invoice Matched to PO
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Matched to PO' AS "ActivityName",
    CAST(MIN(AID.CREATION_DATE) AS TIMESTAMP) AS "EventTime",
    CAST(MIN(AID.CREATION_DATE) AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = MIN(AID.CREATED_BY) AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_INVOICE_DISTRIBUTIONS_ALL AID
JOIN 
    INVOICE_BASE IB ON AID.INVOICE_ID = IB.INVOICE_ID
WHERE
    AID.PO_DISTRIBUTION_ID IS NOT NULL
GROUP BY
    IB.INVOICE_NUM, IB.INVOICE_AMOUNT, IB.VENDOR_NAME, IB.PAYMENT_DUE_DATE, IB.WFAPPROVAL_STATUS, IB.COMPANY_CODE

UNION ALL

-- 4. Matching Discrepancy Identified & 5. Hold Placed on Invoice
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    CASE 
        WHEN AH.HOLD_LOOKUP_CODE IN ('QTY ORD', 'QTY REC', 'PRICE', 'AMT ORD', 'AMT REC') THEN 'Matching Discrepancy Identified'
        ELSE 'Hold Placed on Invoice'
    END AS "ActivityName",
    CAST(AH.HOLD_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AH.HOLD_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AH.CREATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_HOLDS_ALL AH
JOIN 
    INVOICE_BASE IB ON AH.INVOICE_ID = IB.INVOICE_ID

UNION ALL

-- 6. Hold Released from Invoice
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Hold Released from Invoice' AS "ActivityName",
    CAST(AH.RELEASE_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AH.RELEASE_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AH.LAST_UPDATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_HOLDS_ALL AH
JOIN 
    INVOICE_BASE IB ON AH.INVOICE_ID = IB.INVOICE_ID
WHERE 
    AH.RELEASE_LOOKUP_CODE IS NOT NULL AND AH.RELEASE_DATE IS NOT NULL

UNION ALL

-- 7. Invoice Sent for Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    CASE 
        WHEN AAH.ACTION = 'INITIATED' THEN 'Invoice Sent for Approval'
        WHEN AAH.ACTION = 'APPROVED' THEN 'Invoice Approved'
        WHEN AAH.ACTION = 'REJECTED' THEN 'Invoice Rejected'
    END AS "ActivityName",
    CAST(AAH.RESPONSE_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AAH.RESPONSE_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AAH.RESPONSE_ID AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    AP_INV_APRVL_HIST_ALL AAH
JOIN 
    INVOICE_BASE IB ON AAH.INVOICE_ID = IB.INVOICE_ID
WHERE
    AAH.ACTION IN ('INITIATED', 'APPROVED', 'REJECTED') AND AAH.RESPONSE_DATE IS NOT NULL

UNION ALL

-- 10. Invoice Corrected
SELECT DISTINCT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Corrected' AS "ActivityName",
    CAST(IB.LAST_UPDATE_DATE AS TIMESTAMP) AS "EventTime",
    CAST(IB.LAST_UPDATE_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = IB.LAST_UPDATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    INVOICE_BASE IB
WHERE
    IB.LAST_UPDATE_DATE > IB.CREATION_DATE
    AND IB.LAST_UPDATED_BY <> IB.CREATED_BY 
    AND EXISTS (
        SELECT 1 FROM AP_INV_APRVL_HIST_ALL AAH 
        WHERE AAH.INVOICE_ID = IB.INVOICE_ID AND AAH.ACTION = 'REJECTED' AND IB.LAST_UPDATE_DATE > AAH.RESPONSE_DATE
    )

UNION ALL

-- 11. Invoice Accounted
SELECT 
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Accounted' AS "ActivityName",
    CAST(MIN(XAH.ACCOUNTING_DATE) AS TIMESTAMP) AS "EventTime",
    CAST(MIN(XAH.ACCOUNTING_DATE) AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = MIN(XAH.CREATED_BY) AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM XLA_AE_HEADERS XAH
JOIN XLA_TRANSACTION_ENTITIES XTE ON XAH.ENTITY_ID = XTE.ENTITY_ID
JOIN INVOICE_BASE IB ON XTE.SOURCE_ID_INT_1 = IB.INVOICE_ID
WHERE XTE.APPLICATION_ID = 200
AND XTE.ENTITY_CODE = 'AP_INVOICES'
AND XAH.ACCOUNTING_ENTRY_STATUS_CODE = 'F' -- Final
GROUP BY
    IB.INVOICE_NUM, IB.INVOICE_AMOUNT, IB.VENDOR_NAME, IB.PAYMENT_DUE_DATE, IB.WFAPPROVAL_STATUS, IB.COMPANY_CODE

UNION ALL

-- 12. Payment Scheduled
SELECT 
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    CAST(MIN(APISC.CREATION_DATE) AS TIMESTAMP) AS "EventTime",
    CAST(MIN(APISC.CREATION_DATE) AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = MIN(APISC.CREATED_BY) AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM AP_INV_SELECTION_CRITERIA_ALL APISC
JOIN AP_INVOICES_ALL AIA ON APISC.CHECKRUN_NAME = AIA.PAYMENT_STATUS_FLAG
JOIN INVOICE_BASE IB ON AIA.INVOICE_ID = IB.INVOICE_ID
GROUP BY
    IB.INVOICE_NUM, IB.INVOICE_AMOUNT, IB.VENDOR_NAME, IB.PAYMENT_DUE_DATE, IB.WFAPPROVAL_STATUS, IB.COMPANY_CODE

UNION ALL

-- 13. Payment Created
SELECT 
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Payment Created' AS "ActivityName",
    CAST(AIPA.CREATION_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AIPA.CREATION_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AIPA.CREATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM AP_INVOICE_PAYMENTS_ALL AIPA
JOIN INVOICE_BASE IB ON AIPA.INVOICE_ID = IB.INVOICE_ID

UNION ALL

-- 14. Payment Executed
SELECT 
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    CAST(AC.CLEARED_DATE AS TIMESTAMP) AS "EventTime",
    CAST(AC.CLEARED_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = AC.LAST_UPDATED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM AP_INVOICE_PAYMENTS_ALL AIPA
JOIN AP_CHECKS_ALL AC ON AIPA.CHECK_ID = AC.CHECK_ID
JOIN INVOICE_BASE IB ON AIPA.INVOICE_ID = IB.INVOICE_ID
WHERE AC.CLEARED_DATE IS NOT NULL

UNION ALL

-- 15. Invoice Canceled
SELECT
    IB.INVOICE_NUM AS "InvoiceNumber",
    'Invoice Canceled' AS "ActivityName",
    CAST(IB.CANCELLED_DATE AS TIMESTAMP) AS "EventTime",
    CAST(IB.CANCELLED_DATE AS TIMESTAMP) AS "EndTime",
    (SELECT USERNAME FROM PER_USERS PU WHERE PU.USER_ID = IB.CANCELLED_BY AND ROWNUM = 1) AS "UserName",
    IB.INVOICE_AMOUNT AS "InvoiceAmount",
    IB.VENDOR_NAME AS "VendorName",
    IB.PAYMENT_DUE_DATE AS "PaymentDueDate",
    IB.WFAPPROVAL_STATUS AS "InvoiceStatus",
    IB.COMPANY_CODE AS "CompanyCode"
FROM
    INVOICE_BASE IB
WHERE
    IB.CANCELLED_DATE IS NOT NULL

Étapes

Prérequis : vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système, ainsi que les bibliothèques requests et pandas. Vous pouvez les installer avec pip : pip install requests pandas.
Configurez l’API Oracle Fusion : dans votre instance Oracle Fusion, accédez à Security Console. Créez une nouvelle application confidentielle pour obtenir un accès à l’API. Notez le Client ID et le Client Secret attribués. Vérifiez que l’utilisateur de l’application dispose des rôles nécessaires pour lire les données de factures et de paiements, notamment le rôle Financials - Payables Invoice Inquiry Duty.
Configurez le script Python : copiez le script Python fourni dans un fichier, par exemple extract_fusion_invoices.py. Ouvrez le fichier et renseignez les variables d’espace réservé situées en haut du script. Il s’agit notamment de CLIENT_ID, CLIENT_SECRET, TOKEN_URL, FUSION_HOST, START_DATE et END_DATE. FUSION_HOST doit correspondre à l’URL de base de vos applications Oracle Cloud.
Définissez la période d’extraction : modifiez les variables START_DATE et END_DATE pour définir la période d’extraction. Il est recommandé de commencer par une période courte, par exemple un mois, afin de tester le script et de vérifier le résultat.
Exécutez le script : lancez le script depuis la ligne de commande ou le terminal en accédant à son répertoire, puis en saisissant python extract_fusion_invoices.py. Le script s’authentifie, récupère les données et affiche des messages de progression dans la console.
Processus d’authentification : le script envoie d’abord une requête contenant vos identifiants client au fournisseur d’identité Oracle (TOKEN_URL) afin d’obtenir un jeton d’accès OAuth. Ce jeton est ensuite inclus dans l’en-tête de toutes les requêtes API suivantes pour l’authentification auprès de l’API Fusion Financials.
Récupération et pagination des données : le script interroge le point de terminaison de l’API REST invoices afin de récupérer les enregistrements créés pendant la période indiquée. Il gère automatiquement la pagination en vérifiant l’indicateur hasMore dans la réponse de l’API et en envoyant des requêtes successives avec une valeur offset mise à jour jusqu’à la récupération de toutes les données de factures.
Récupération des informations détaillées : pour chaque facture récupérée, le script effectue des appels API supplémentaires afin d’obtenir les informations associées. Il interroge le point de terminaison /child/holds pour les informations de retenue et de libération, ainsi que le point de terminaison /payments, filtré par numéro de facture, pour récupérer les données de paiement.
Génération de l’Event Log : la logique principale du script traite les données JSON brutes de l’API. Elle vérifie certaines dates, certains statuts et certains enregistrements enfants afin de générer une ligne distincte pour chacune des 15 activités métier requises. Par exemple, la présence de CancelledDate génère un événement « Invoice Canceled ».
Vérifiez le résultat : une fois le script terminé, il crée un fichier nommé invoice_event_log.csv dans le même répertoire. Ouvrez ce fichier CSV avec un tableur pour examiner les données. Vérifiez que toutes les colonnes requises (InvoiceNumber, ActivityName, EventTime) et les attributs recommandés sont présentes.
Préparez le chargement : vérifiez que les en-têtes de colonnes du fichier CSV correspondent aux noms des attributs requis. Aucune autre mise en forme n’est généralement nécessaire. Le fichier est désormais prêt à être chargé dans votre outil de Process Mining.

Configuration

Identifiants d’authentification : un Client ID et un Client Secret issus d’une application confidentielle enregistrée dans la Security Console d’Oracle Fusion sont requis. L’URL Token URL de votre domaine d’identité doit également être fournie.
URL de l’hôte API : la variable FUSION_HOST doit être définie sur l’URL de base de votre instance Oracle Fusion, par exemple https://[your-instance].fa.us2.oraclecloud.com.
Période : les variables START_DATE et END_DATE sont essentielles pour contrôler le périmètre de l’extraction. Pour une première analyse, il est recommandé d’extraire 3 à 6 mois de données afin de trouver un équilibre entre le volume de données et les performances.
Points de terminaison API utilisés : le script interagit principalement avec les points de terminaison fscmRestApi/resources/11.13.18.05/invoices et fscmRestApi/resources/11.13.18.05/payments. Il utilise également la sous-ressource /invoices/{InvoiceId}/child/holds.
Limite de pagination : la variable LIMIT du script contrôle le nombre d’enregistrements récupérés par requête API. La valeur par défaut est 100. Une valeur plus élevée peut réduire le nombre d’appels API, mais augmenter la consommation de mémoire par requête. Une valeur plus faible peut être nécessaire si vous rencontrez des erreurs de délai d’expiration.
Autorisations requises : le compte utilisateur associé aux identifiants API doit disposer d’un accès en lecture aux factures des comptes fournisseurs, aux retenues sur factures, aux paiements et aux informations sur les fournisseurs. Le rôle Payables Invoice Inquiry Duty fournit généralement les autorisations suffisantes.

a Exemple de requête python

import requests
import pandas as pd
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 credentials and instance details
CLIENT_ID = class="hl-string">'[Your Client ID]'
CLIENT_SECRET = class="hl-string">'[Your Client Secret]'
TOKEN_URL = class="hl-string">'[Your Oracle Identity Cloud Service Token URL, e.g., https://idcs-....identity.oraclecloud.com/oauth2/v1/token]'
FUSION_HOST = class="hl-string">'[Your Fusion Host URL, e.g., https://your-fusion-instance.fa.ocs.oraclecloud.com]'

class=class="hl-string">"hl-comment"># --- Extraction Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the invoice extraction (YYYY-MM-DD)
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-06-30'

class=class="hl-string">"hl-comment"># API request settings
LIMIT = 100

class=class="hl-string">"hl-comment"># --- Helper Functions ---
def get_access_token():
    class="hl-string">"""Authenticates and retrieves an OAuth2 access token."""
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    data = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'scope': class="hl-string">'urn:opc:resource:consumer::all'
    }
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data, auth=(CLIENT_ID, CLIENT_SECRET))
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def fetch_data(api_url, headers, params):
    class="hl-string">"""Fetches data from a given API endpoint with pagination handling."""
    all_items = []
    offset = 0
    has_more = True

    while has_more:
        params[class="hl-string">'offset'] = offset
        try:
            response = requests.get(api_url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            items = data.get(class="hl-string">'items', [])
            all_items.extend(items)
            has_more = data.get(class="hl-string">'hasMore', False)
            offset += len(items)
            print(fclass="hl-string">"Fetched {len(all_items)} records so far...")
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {api_url}: {e}")
            print(fclass="hl-string">"Response content: {response.text}")
            break
    return all_items

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    class="hl-string">"""Main function to extract, transform, and save invoice data."""
    access_token = get_access_token()
    if not access_token:
        print(class="hl-string">"Could not obtain access token. Exiting.")
        return

    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourceitem+json'
    }

    event_log = []

    class=class="hl-string">"hl-comment"># 1. Fetch Invoices
    print(class="hl-string">"Starting invoice extraction...")
    invoice_url = fclass="hl-string">'{FUSION_HOST}/fscmRestApi/resources/11.13.18.05/invoices'
    invoice_params = {
        class="hl-string">'q': fclass="hl-string">'CreationDate between \'{START_DATE}T00:00:00.000Z\class="hl-string">' and \'{END_DATE}T23:59:59.999Z\class="hl-string">'',
        class="hl-string">'onlyData': class="hl-string">'true',
        class="hl-string">'limit': LIMIT,
        class="hl-string">'fields': class="hl-string">'InvoiceId,InvoiceNumber,InvoiceAmount,CreationDate,CreatedBy,LastUpdateDate,LastUpdatedBy,SupplierName,ValidationDate,CancelledDate,ApprovalStatus,AccountingDate,PaymentStatus,DueDate,InvoiceStatus,BusinessUnitName'
    }
    invoices = fetch_data(invoice_url, headers, invoice_params)
    print(fclass="hl-string">"Total invoices fetched: {len(invoices)}")

    class=class="hl-string">"hl-comment"># 2. Process each invoice to create events
    for inv in invoices:
        case_id = inv.get(class="hl-string">'InvoiceNumber')
        if not case_id:
            continue

        base_event = {
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'EndTime': None,
            class="hl-string">'InvoiceAmount': inv.get(class="hl-string">'InvoiceAmount'),
            class="hl-string">'VendorName': inv.get(class="hl-string">'SupplierName'),
            class="hl-string">'PaymentDueDate': inv.get(class="hl-string">'DueDate'),
            class="hl-string">'InvoiceStatus': inv.get(class="hl-string">'InvoiceStatus'),
            class="hl-string">'CompanyCode': inv.get(class="hl-string">'BusinessUnitName')
        }

        class=class="hl-string">"hl-comment"># Activity: Invoice Created
        if inv.get(class="hl-string">'CreationDate'):
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTime': inv[class="hl-string">'CreationDate'], class="hl-string">'UserName': inv.get(class="hl-string">'CreatedBy')})

        class=class="hl-string">"hl-comment"># Activity: Invoice Validated
        if inv.get(class="hl-string">'ValidationDate'):
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Validated', class="hl-string">'EventTime': inv[class="hl-string">'ValidationDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        
        class=class="hl-string">"hl-comment"># Activities based on Approval Status
        if inv.get(class="hl-string">'ApprovalStatus') in [class="hl-string">'Initiated', class="hl-string">'Required']:
             event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Sent for Approval', class="hl-string">'EventTime': inv[class="hl-string">'LastUpdateDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        elif inv.get(class="hl-string">'ApprovalStatus') in [class="hl-string">'Approved', class="hl-string">'Not required', class="hl-string">'Workflow approved']:
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Approved', class="hl-string">'EventTime': inv[class="hl-string">'LastUpdateDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'Rejected':
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Rejected', class="hl-string">'EventTime': inv[class="hl-string">'LastUpdateDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        
        class=class="hl-string">"hl-comment"># This is an inference, might represent corrections after rejection or validation failure
        if inv.get(class="hl-string">'InvoiceStatus') == class="hl-string">'Needs revalidation':
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Corrected', class="hl-string">'EventTime': inv[class="hl-string">'LastUpdateDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})

        class=class="hl-string">"hl-comment"># Activity: Invoice Accounted
        if inv.get(class="hl-string">'AccountingDate'):
             event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Accounted', class="hl-string">'EventTime': inv[class="hl-string">'AccountingDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})

        class=class="hl-string">"hl-comment"># Activity: Invoice Canceled
        if inv.get(class="hl-string">'CancelledDate'):
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Canceled', class="hl-string">'EventTime': inv[class="hl-string">'CancelledDate'], class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})
        
        class=class="hl-string">"hl-comment"># Activity: Matched to PO - Inference based on PaymentStatus which can indicate matching holds resolved
        if inv.get(class="hl-string">'PaymentStatus') == class="hl-string">'Available':
             event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Invoice Matched to PO', class="hl-string">'EventTime': inv.get(class="hl-string">'ValidationDate') or inv.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': inv.get(class="hl-string">'LastUpdatedBy')})

        class=class="hl-string">"hl-comment"># 3. Fetch Holds for the Invoice
        holds_url = fclass="hl-string">'{FUSION_HOST}/fscmRestApi/resources/11.13.18.05/invoices/{inv["InvoiceId"]}/child/holds'
        holds = fetch_data(holds_url, headers, {class="hl-string">'onlyData': class="hl-string">'true'})
        for hold in holds:
            class=class="hl-string">"hl-comment"># Activity: Hold Placed on Invoice
            event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Hold Placed on Invoice', class="hl-string">'EventTime': hold[class="hl-string">'HoldDate'], class="hl-string">'UserName': hold.get(class="hl-string">'LastUpdatedBy')})
            if hold.get(class="hl-string">'HoldReason') in [class="hl-string">'Price', class="hl-string">'Qty Ord', class="hl-string">'Qty Rec', class="hl-string">'Quality']:
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Identified', class="hl-string">'EventTime': hold[class="hl-string">'HoldDate'], class="hl-string">'UserName': hold.get(class="hl-string">'LastUpdatedBy')})
            
            class=class="hl-string">"hl-comment"># Activity: Hold Released from Invoice
            if hold.get(class="hl-string">'ReleaseDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Hold Released from Invoice', class="hl-string">'EventTime': hold[class="hl-string">'ReleaseDate'], class="hl-string">'UserName': hold.get(class="hl-string">'LastUpdatedBy')})

        class=class="hl-string">"hl-comment"># 4. Fetch Payments for the Invoice
        if inv.get(class="hl-string">'PaymentStatus') in [class="hl-string">'Paid', class="hl-string">'Partially paid']:
            payment_url = fclass="hl-string">'{FUSION_HOST}/fscmRestApi/resources/11.13.18.05/payments'
            payment_params = {
                class="hl-string">'q': fclass="hl-string">'InvoiceNumber=\'{case_id}\class="hl-string">'',
                class="hl-string">'onlyData': class="hl-string">'true',
                class="hl-string">'fields': class="hl-string">'PaymentId,CreationDate,CreatedBy,ClearedDate,PaymentDate'
            }
            payments = fetch_data(payment_url, headers, payment_params)
            for pmt in payments:
                 class=class="hl-string">"hl-comment"># Activity: Payment Scheduled (Approximation using Payment Creation Date)
                 event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Payment Scheduled', class="hl-string">'EventTime': pmt[class="hl-string">'CreationDate'], class="hl-string">'UserName': pmt.get(class="hl-string">'CreatedBy')})
                 class=class="hl-string">"hl-comment"># Activity: Payment Created
                 event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Payment Created', class="hl-string">'EventTime': pmt[class="hl-string">'PaymentDate'], class="hl-string">'UserName': pmt.get(class="hl-string">'CreatedBy')})
                 class=class="hl-string">"hl-comment"># Activity: Payment Executed
                 if pmt.get(class="hl-string">'ClearedDate'):
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Payment Executed', class="hl-string">'EventTime': pmt[class="hl-string">'ClearedDate'], class="hl-string">'UserName': pmt.get(class="hl-string">'CreatedBy')})

    class=class="hl-string">"hl-comment"># 5. Create and Save DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. Please check your date range and API responses.")
        return

    df = pd.DataFrame(event_log)
    df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    if class="hl-string">'EndTime' in df.columns:
         df[class="hl-string">'EndTime'] = pd.to_datetime(df[class="hl-string">'EndTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

    output_filename = class="hl-string">'invoice_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

Prêt à commencer ?

Commencez à optimiser votre traitement des factures en préparant vos données avec ce modèle. Obtenez des analyses utiles et réalisez des gains d’efficacité importants dans votre organisation.

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

Optimisez dès maintenant le traitement de vos factures P2P pour réduire de 30 % la durée des cycles

Éliminez les goulots d’étranglement dans Oracle Fusion Financials et réduisez le temps de cycle de 30 %.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Observez des résultats en quelques jours.

Votre modèle de données Purchase to Pay, traitement des factures

Votre modèle de données Purchase to Pay, traitement des factures

Purchase to Pay - Attributs du traitement des factures

Purchase to Pay - Activités de traitement des factures

Guides d’extraction

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

Étapes

Configuration

a Exemple de requête sql

Rapport Oracle BI Publisher avec modèle de données SQL personnalisé

Étapes

Configuration

a Exemple de requête sql

Extraction avec un script Python via l’API REST de Fusion Financials

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant le traitement de vos factures P2P pour réduire de 30 % la durée des cycles

Votre modèle de données Purchase to Pay, traitement des factures

Votre modèle de données Purchase to Pay, traitement des factures

Purchase to Pay - Attributs du traitement des factures

Purchase to Pay - Activités de traitement des factures

Guides d’extraction

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

Étapes

Configuration

a Exemple de requête sql

Rapport Oracle BI Publisher avec modèle de données SQL personnalisé

Étapes

Configuration

a Exemple de requête sql

Extraction avec un script Python via l’API REST de Fusion Financials

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant le traitement de vos factures P2P pour réduire de 30 % la durée des cycles

Nous attachons de l’importance à votre confidentialité