> Amélioration continue des processus > Achats au paiement : 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

Attributs du processus Purchase to Pay, traitement des factures(20) Activités du processus Purchase to Pay, 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, et plus particulièrement du traitement des factures dans Oracle Fusion Financials. Il présente les attributs et les activités clés, et explique comment extraire ces informations de votre système. Vous pourrez ainsi préparer un journal d’événements complet et précis 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 ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du processus Purchase to Pay, traitement des factures

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser en détail le processus Purchase to Pay de traitement des factures.

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 de cas principal. Il relie toutes les activités et tous les événements associés à une facture fournisseur, de sa création à son paiement final. Chaque facture constitue un cas distinct dans l’analyse du processus. En Process Mining, cet attribut est fondamental pour reconstituer le parcours complet de chaque facture. Il permet d’analyser les flux de processus, les temps de cycle et les variations pour chaque facture. Il relie les différentes activités, comme la validation, l’approbation et le paiement, pour former une vue cohérente du processus. Pourquoi est-ce important ? Cet identifiant de cas essentiel relie toutes les étapes associées et permet de suivre le cycle de vie complet d’une facture. Où trouver ces données Cet attribut se trouve généralement dans la colonne INVOICE_NUM de la table AP_INVOICES_ALL. Exemples INV-2023-001987654321ACME-FIN-5501
	Activité ActivityName	Nom de l’activité métier ou de l’événement qui s’est produit dans le processus de traitement des factures.
Description Cet attribut décrit une étape précise ou un changement de statut dans le cycle de vie de la facture, par exemple « Facture créée », « Facture approuvée » ou « Paiement effectué ». Il constitue la séquence d’événements qui forme 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, de repérer les goulots d’étranglement où les activités prennent du retard, et de détecter les écarts ou les boucles de reprise, par exemple lorsqu’une facture est rejetée après son approbation. Pourquoi est-ce important ? Cet attribut définit les étapes du processus. Il est essentiel pour visualiser la cartographie du processus, analyser les variations du flux et repérer les goulots d’étranglement. Où trouver ces données Cet attribut est généralement établi à partir 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éeFacture mise en attenteFacture approuvéePaiement effectué
	Heure de début EventTime	Horodatage indiquant le moment où une activité ou un événement s’est produit.
Description Cet attribut indique la date et l’heure de chaque activité du processus de traitement des factures. Il est indispensable à toutes les analyses temporelles du processus, notamment au calcul des temps de cycle, des durées et des temps d’attente entre les étapes. En classant les événements par ordre chronologique à partir de cet horodatage, les outils de Process Mining peuvent reconstituer la séquence exacte des activités pour chaque facture. Ils peuvent ainsi calculer des indicateurs de performance clés, comme le temps moyen de cycle des factures, et repérer les étapes qui prennent le plus de temps. Pourquoi est-ce important ? Cet horodatage est indispensable au calcul des indicateurs de performance liés aux durées et au temps, notamment les temps de cycle et les goulots d’étranglement. Où trouver ces données Cet horodatage est établi à partir de différents champs de date dans les tables Oracle Fusion, comme CREATION_DATE ou LAST_UPDATE_DATE dans AP_INVOICES_ALL ou dans 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é désigne l’entité 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 des processus par entité juridique. Vous pouvez ainsi comparer les performances entre différentes parties de l’entreprise, repérer les goulots d’étranglement ou les problèmes de conformité propres à une entité et produire des KPI à l’échelle de chaque société. Le code société intervient souvent aussi dans le choix du circuit d’approbation approprié. Pourquoi est-ce important ? Il permet de comparer les processus et leurs performances entre les différentes entités juridiques ou unités opérationnelles de l’organisation. Où trouver ces données Cette information est généralement représentée par le champ LEGAL_ENTITY_ID, ou un champ similaire, dans AP_INVOICES_ALL. Celui-ci peut être relié aux tables du grand livre pour 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 indispensable au Dashboard « Performance des paiements dans les délais » et au KPI associé. En comparant l’horodatage réel de l’exécution du paiement à la date d’échéance, l’analyse permet de classer les paiements comme effectués dans les délais ou en retard. L’organisation peut ainsi suivre et améliorer le respect des échéances de paiement. Pourquoi est-ce important ? Cette date sert de référence pour mesurer le respect des délais de paiement, un KPI important pour la gestion des fournisseurs et la santé financière. Où trouver ces données Cette date figure souvent dans les tables d’échéancier de paiement, comme AP_PAYMENT_SCHEDULES_ALL, reliées à la facture. Exemples 2023-05-152023-06-012023-06-30
	Heure de fin EndTime	Horodatage indiquant la fin d’une activité ou d’un événement.
Description L’heure de fin marque l’achèvement d’une activité donnée. Alors que l’heure de début indique son commencement, l’heure de fin en marque le terme et permet de calculer précisément la durée de chaque étape. Dans le cadre de l’analyse, la différence entre l’heure de fin et l’heure de début correspond à la durée de traitement de chaque activité. Cette mesure est essentielle pour analyser les performances en détail et 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 opposition au temps pendant lequel la tâche est restée dans sa file d’attente. Pourquoi est-ce important ? Cet attribut permet de calculer précisément la durée de traitement des activités et de distinguer le temps de travail actif du temps d’attente. Où trouver ces données Il s’agit d’un attribut conceptuel, calculé à partir de l’heure de début de l’événement suivant dans la séquence d’un dossier donné. Exemples 2023-04-15T10:05:12Z2023-04-16T15:00:00Z2023-04-20T09:15:30Z
	Montant de la facture InvoiceAmount	Montant total de la facture.
Description Le montant de la facture correspond à la somme totale due au fournisseur, telle qu’elle figure sur la facture. Cet attribut financier important influe sur l’ensemble du processus : il détermine souvent 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 un critère essentiel de filtrage et de segmentation. Les analystes peuvent, par exemple, comparer le traitement des factures de montant élevé à celui des factures de faible montant afin de vérifier si les circuits diffèrent ou si les temps de cycle varient sensiblement. Cet attribut est également nécessaire au calcul des KPI financiers et à l’évaluation de l’impact financier des inefficacités, comme les retards de paiement. Pourquoi est-ce important ? Cette valeur est essentielle à l’analyse financière, à l’étude des écarts du processus selon le montant et au calcul de KPI tels que le taux de conformité des approbations. Où trouver ces données Dans la table AP_INVOICES_ALL, colonne INVOICE_AMOUNT. Exemples 1500.00250.75125000.50
	Nom d’utilisateur UserName	Nom de l’utilisateur qui a effectué l’activité.
Description Cet attribut identifie l’utilisateur ou l’agent système qui a effectué une activité, par exemple valider une facture, la mettre en attente ou approuver un paiement. Il apporte au processus une dimension liée aux ressources humaines ou système. L’analyse par utilisateur permet de comprendre la répartition de la charge de travail, de repérer les personnes les plus performantes et de détecter d’éventuels besoins de formation ou problèmes de conformité. Elle peut, par exemple, révéler que certains utilisateurs sont régulièrement associés à des boucles de reprise ou que les mêmes personnes traitent systématiquement certaines étapes d’approbation, ce qui crée un risque de dépendance à une seule personne. Pourquoi est-ce important ? Il permet d’analyser la performance des ressources, de répartir la charge de travail et de déterminer quels utilisateurs ou quelles équipes interviennent à chaque étape du processus. Où trouver ces données Ces informations sont souvent enregistrées dans des colonnes d’audit telles que CREATED_BY ou LAST_UPDATED_BY, dans des tables comme AP_INVOICES_ALL, ou dans les 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 le fournisseur auquel se rapporte la facture. Ces informations apportent un contexte commercial important à la transaction financière. L’analyse du processus par fournisseur peut mettre en évidence des éléments importants concernant les relations avec les fournisseurs et leurs performances. Elle peut, par exemple, montrer que les factures de certains fournisseurs présentent plus souvent des écarts de rapprochement, des blocages ou des retards. Ces informations peuvent servir à améliorer l’intégration des fournisseurs, la communication avec eux et l’efficacité globale de la chaîne d’approvisionnement. Elles permettent également de repérer d’éventuels paiements en double. Pourquoi est-ce important ? Il permet d’analyser le processus pour chaque fournisseur et de repérer les problèmes propres à certains fournisseurs qui entraînent des retards ou des exceptions. Où trouver ces données Dans la table POZ_SUPPLIERS. La table des factures AP_INVOICES_ALL contient un VENDOR_ID qui permet de la relier à 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 indique le dernier état connu de la facture, par exemple « Validée », « À revalider », « Payée » ou « Annulée ». Il donne un aperçu de l’étape à laquelle se trouve la facture dans le processus à un moment donné. Le statut de la facture est essentiel au Dashboard « Répartition des statuts actuels des factures », qui aide les responsables des opérations à repérer les retards accumulés et à suivre l’état général du traitement des factures. L’analyse de l’évolution des statuts dans le temps donne également une vue simplifiée du flux de processus. Pourquoi est-ce important ? Il donne une vue de l’état actuel des factures, indispensable aux Dashboards opérationnels qui suivent les retards accumulés et la charge de travail. Où trouver ces données Consultez la documentation Oracle Fusion Financials. Le statut peut être déterminé à partir 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 requise
	Date de la facture InvoiceDate	Date indiquée sur la 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 convenues. Même si elle ne marque pas toujours le début du processus interne, la date de la facture apporte un contexte important. Associée au nom du fournisseur et au montant de la facture, elle aide à repérer d’éventuels doublons. L’analyse du délai entre la date de la facture et sa création dans le système peut également révéler des inefficacités dans le traitement du courrier ou l’importation des factures. Pourquoi est-ce important ? Cette date est essentielle pour repérer les factures en double et calculer les dates d’échéance des paiements. Où trouver ces données 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 dernière modification 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. Même s’il n’intervient pas directement dans l’analyse des flux de processus, cet horodatage technique est essentiel pour garantir l’actualité et 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 est-ce important ? Il permet d’exécuter efficacement les pipelines de données de manière incrémentielle et de maintenir l’analyse des processus à jour sans rechargement complet. Où trouver ces données Cet attribut apparaît souvent sous le nom LAST_UPDATE_DATE dans les tables Oracle Fusion, notamment AP_INVOICES_ALL. Exemples 2023-05-20T11:00:00Z2023-05-21T16:45:00Z
	Devise InvoiceCurrencyCode	Devise du montant de la facture.
Description Cet attribut indique la devise dans laquelle la facture est libellée, par exemple USD, EUR ou GBP. Il apporte un contexte indispensable au champ du montant de la facture. Dans une organisation internationale, l’analyse des factures par devise est importante pour les rapports financiers et l’étude des différences entre 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 est-ce important ? Il apporte le contexte nécessaire à l’interprétation et à l’analyse des montants financiers, en particulier dans les activités menées dans plusieurs pays. Où trouver ces données Dans la table AP_INVOICES_ALL, colonne INVOICE_CURRENCY_CODE. Exemples USDEURGBPCAD
	Motif de l’écart de rapprochement MatchingDiscrepancyReason	Motif précis de l’écart entre une facture, un bon de commande et un reçu.
Description Cet attribut précise pourquoi une facture n’a pas passé le rapprochement automatisé. Les motifs courants comprennent les écarts de prix, de quantité ou de code article entre la facture et le bon de commande ou le reçu de marchandises correspondant. Ces informations sont essentielles au Dashboard « Taux d’écart de rapprochement des factures ». En classant et en analysant les motifs des écarts, les entreprises peuvent repérer les problèmes systémiques dans leurs processus d’approvisionnement ou de réception. Elles peuvent alors prendre des mesures correctives pour augmenter la part des factures traitées de bout en bout sans intervention manuelle. Pourquoi est-ce important ? Il explique pourquoi les factures échouent au rapprochement automatisé et aide à améliorer le taux de rapprochement dès la première tentative et à réduire les reprises manuelles. Où trouver ces données Consultez la documentation Oracle Fusion Financials. Le motif peut être enregistré comme type de blocage 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 commandeLa quantité facturée dépasse la quantité reçueArticle invalide sur la facture
	Motif de mise en attente HoldReason	Motif de la mise en attente ou du blocage du paiement d’une facture.
Description Lorsqu’une facture est mise en attente, cet attribut en précise le motif, par exemple « Écart de prix », « Écart de quantité » ou « Réception des marchandises en attente ». Il explique pourquoi le déroulement normal du processus a été interrompu. Cet attribut est le principal critère du Dashboard « Tendances et analyse des blocages de paiement ». En analysant la fréquence des différents motifs de mise en attente, l’entreprise peut repérer et traiter les causes profondes des blocages, comme des problèmes dans les processus d’approvisionnement ou des erreurs dans les factures des fournisseurs, et ainsi réduire les délais de traitement. Pourquoi est-ce important ? Il indique la cause profonde des blocages de paiement et permet de cibler les améliorations afin de réduire les mises en attente et les retards de paiement. Où trouver ces données Les informations sur les mises en attente sont généralement enregistrées dans la table AP_HOLDS_ALL, reliée à la facture et contenant un motif ou un code de blocage. Exemples Écart de prixLa quantité facturée dépasse la quantité reçueNuméro de commande invalide
	Nom de l’approbateur ApproverName	Nom de la personne qui a approuvé ou rejeté la facture.
Description Cet attribut indique l’identité de la personne qui est intervenue à l’étape d’approbation. Il est renseigné pour des activités telles que « Facture approuvée » ou « Facture rejetée ». L’analyse du nom de l’approbateur permet de comprendre la répartition des approbations, de mesurer les temps de cycle de chaque approbateur et de vérifier le respect des règles d’approbation. Pour le KPI de taux de conformité des approbations, cet attribut peut être comparé aux règles de délégation de pouvoirs, en fonction du montant de la facture et du code société. Pourquoi est-ce important ? Cet attribut est essentiel pour analyser les temps de cycle des approbations, vérifier le respect des règles de la matrice d’approbation et comprendre la répartition de la charge de travail. Où trouver ces données Ces informations figurent dans les tables Oracle Fusion consacrées au flux de travail ou à l’historique des approbations associées à la facture. Exemples David WilsonSarah JohnsonMichael Brown
	Numéro de bon de commande PurchaseOrderNumber	Identifiant du bon de commande associé à la facture.
Description Cet attribut relie la facture au bon de commande (PO) correspondant, qui autorise l’achat des biens ou des services. Les factures peuvent être associées à un bon de commande ou ne pas l’être. L’analyse par bon de commande relie le traitement des factures à la partie approvisionnement du processus P2P. Elle aide à évaluer le respect des règles d’approvisionnement et à déterminer si les problèmes de facturation, comme les écarts de rapprochement, proviennent de problèmes liés au bon de commande initial. La présence ou l’absence d’un numéro de bon de commande constitue un critère essentiel pour segmenter et analyser les différents circuits de traitement des factures. Pourquoi est-ce important ? Il relie la facture au processus d’approvisionnement et permet notamment de comparer les circuits des factures associées à un bon de commande à ceux des factures qui n’en ont pas. Où trouver ces données Ces informations sont accessibles en reliant les lignes de facture de AP_INVOICE_LINES_ALL aux distributions de bons de commande via PO_DISTRIBUTION_ID. Exemples PO-2023-5001600789PO-FIN-9981
	Paiement effectué dans les délais IsOnTimePayment	Indicateur booléen précisant si la facture a été payée au plus tard à sa date d’échéance.
Description Cet indicateur prend la valeur « vrai » si le paiement a été effectué au plus tard à la date d’échéance prévue, et « faux » dans le cas contraire. Il permet de classer simplement et clairement chaque facture payée. Cet attribut calculé contribue directement au KPI de taux de paiement dans les délais et au Dashboard associé. Il simplifie l’analyse en permettant de filtrer, de compter et de visualiser facilement la part des paiements en retard et de ceux effectués dans les délais, sans avoir à comparer les dates à chaque fois. Vous pouvez ainsi repérer rapidement l’ampleur des retards de paiement et suivre leur évolution. Pourquoi est-ce important ? Il simplifie l’analyse du respect des délais de paiement et sert directement au calcul du KPI de taux de paiement dans les délais. Où trouver ces données Cet attribut calculé résulte de la comparaison entre l’horodatage de l’activité « Paiement effectué » et l’attribut « PaymentDueDate ». Exemples truefalse
	Reprise IsRework	Indicateur booléen qui identifie les activités faisant partie d’une boucle de reprise.
Description Cet indicateur prend la valeur « vrai » pour les activités qui signalent un écart par rapport au déroulement prévu du processus, comme « Facture corrigée » ou une deuxième activité « Facture validée » après un rejet. Il permet d’identifier et de quantifier explicitement les boucles de processus inefficaces. Cet attribut est essentiel au Dashboard « Taux de reprises et de traitement des exceptions ». En signalant les activités de reprise, il aide les analystes à en quantifier le volume et le coût, à en repérer les causes profondes et à mesurer les effets des initiatives d’amélioration visant à obtenir un résultat correct dès la première tentative. Pourquoi est-ce 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 l’efficacité du processus. Où trouver ces données 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 des reprises. 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 indique l’application ou le module source qui a généré les données, par exemple Oracle Fusion Financials. Dans les environnements où plusieurs systèmes sont intégrés, il permet de distinguer l’origine des différentes étapes du processus. La connaissance du système source facilite la validation des données, le dépannage et l’analyse des variations propres à un système. Elle clarifie les environnements informatiques complexes où le parcours d’une facture peut s’étendre sur plusieurs applications. Pourquoi est-ce important ? Cet attribut précise l’origine des données, une information utile à leur gouvernance, au dépannage et à l’analyse du comportement propre à chaque système. Où trouver ces données 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

Activités du processus Purchase to Pay, traitement des factures

Voici les étapes et les jalons clés à enregistrer dans votre journal d’événements pour découvrir le processus avec précision.

6 Recommandé 9 Facultatif

	Activité	Description
	Facture approuvée	La facture a reçu l’approbation de toutes les parties requises dans le flux de travail. Elle peut désormais être comptabilisée et son paiement planifié.
Pourquoi est-ce important ? Cette étape importante marque la fin du processus d’approbation. Les retards qui la précèdent constituent souvent des goulots d’étranglement. Où trouver ces données Déduit du passage de `APPROVAL_STATUS` dans la table `AP_INVOICES_ALL` à un état final d’approbation, tel que « Approuvé » ou « Approuvé par le flux de travail ». L’historique d’audit de ce champ fournit l’horodatage. Données à recueillir Déduit du changement de statut de AP_INVOICES_ALL.APPROVAL_STATUS à « Approved ». Type d’événement inferred
	Facture comptabilisée	La facture est comptabilisée dans le grand livre, ce qui génère des écritures. Cet événement confirme que son incidence financière a été officiellement enregistrée.
Pourquoi est-ce important ? Cette étape constitue un point de contrôle financier important et une condition préalable au paiement. Elle confirme que la facture est entièrement validée et approuvée, et qu’elle peut être réglée. Où trouver ces données 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, comme XLA_AE_HEADERS. Données à recueillir Déduit des indicateurs dans AP_INVOICE_DISTRIBUTIONS_ALL ou des écritures associées dans le grand livre. Type d’événement inferred
	Facture créée	Correspond à la création initiale d’une facture dans le système, par saisie manuelle, numérisation ou envoi électronique. Cet événement est généralement enregistré lors de l’ajout d’une ligne dans la table principale des factures.
Pourquoi est-ce important ? Cet événement marque le début du cycle de traitement de la facture. L’analyse du délai qui le suit permet d’évaluer l’efficacité de la saisie et les retards au démarrage du processus. Où trouver ces données Dans Oracle Fusion Financials, cet événement correspond à l’horodatage de création de l’enregistrement dans la table AP_INVOICES_ALL, plus précisément à la colonne CREATION_DATE. Données à recueillir 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 régi par les règles métier configurées. Cette étape marque le début du cycle officiel d’approbation.
Pourquoi est-ce important ? Cette étape lance une partie essentielle du processus. Le suivi de son heure de début est indispensable pour mesurer et optimiser le « Temps de cycle d’approbation des factures ». Où trouver ces données 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 du flux de travail peuvent également contenir cet événement. Données à recueillir Déduit du changement de statut de AP_INVOICES_ALL.APPROVAL_STATUS à « Initiated ». Type d’événement inferred
	Facture rapprochée avec le bon de commande	Cette activité indique que la ligne de facture a été rapprochée avec succès de la ligne correspondante du 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 automatique ou manuelle enregistrée dans le système.
Pourquoi est-ce important ? Cette étape est essentielle au rapprochement à trois voies, qui porte sur le bon de commande, la réception et la facture. Les échecs à ce stade sont une cause fréquente d’exceptions et de retards. Où trouver ces données L’événement peut être déduit de la création d’enregistrements dans la table AP_INVOICE_DISTRIBUTIONS_ALL, qui relient 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é. Données à recueillir Déduit du renseignement des données de distribution du bon de commande sur les lignes de facture. Type d’événement inferred
	Paiement effectué	Cette étape confirme que le paiement a été effectué et compensé. Pour un chèque, il s’agit de la date de compensation ; pour un paiement électronique, de la confirmation de la banque.
Pourquoi est-ce important ? Cette activité clôt le cycle de la facture et marque la fin du processus. Elle sert de point final au calcul du « Temps moyen de cycle des factures » et du « Taux de paiement dans les délais ». Où trouver ces données Déduit du passage du statut du paiement à « Cleared » ou « Reconciled » dans la table AP_CHECKS_ALL (à partir de CLEARED_DATE), ou des données de rapprochement bancaire du module Cash Management (CE_STATEMENT_LINES). Données à recueillir Déduit des mises à jour de statut dans AP_CHECKS_ALL ou du rapprochement dans le module CE. Type d’événement inferred
	Écart de rapprochement détecté	Survient lorsque le système ou un utilisateur repère un écart entre les informations de la facture, du bon de commande et de la réception, par exemple sur le prix ou la quantité. La facture est alors souvent mise en attente par le système.
Pourquoi est-ce important ? Cet événement met en évidence les exceptions qui nécessitent une intervention manuelle. Son suivi est essentiel pour calculer le KPI « Taux d’écarts de rapprochement des factures » et analyser les causes. Où trouver ces données L’événement est souvent enregistré sous la forme d’un type précis de mise en attente de la facture. Consultez la table AP_HOLDS_ALL pour repérer les motifs liés au rapprochement, par exemple « QTY REC » ou « PRICE ». HOLD_DATE indique l’horodatage. Données à recueillir Création d’un enregistrement dans AP_HOLDS_ALL avec un motif de mise en attente lié au rapprochement. Type d’événement explicit
	Facture annulée	La facture a été annulée ou invalidée. Elle ne sera ni traitée davantage ni payée. Cet événement marque la fin du processus pour cette facture.
Pourquoi est-ce important ? Cette étape marque la fin du parcours des factures qui ne donnent pas lieu à un paiement. L’analyse des annulations peut révéler des doublons ou des erreurs dans les factures envoyées par les fournisseurs. Où trouver ces données Déduit d’un changement de statut dans AP_INVOICES_ALL. La colonne CANCELLED_DATE est renseignée avec l’horodatage de l’annulation. Données à recueillir Le champ CANCELLED_DATE de la table AP_INVOICES_ALL est renseigné. Type d’événement explicit
	Facture corrigée	Survient lorsqu’un utilisateur modifie une facture, souvent à la suite d’un rejet ou pour corriger une erreur de saisie. Il s’agit d’une étape de reprise manuelle dans le processus.
Pourquoi est-ce important ? Cette activité indique clairement une reprise. L’analyse de sa fréquence permet de mesurer les inefficacités du processus et contribue au calcul du KPI « Taux de reprise des factures ». Où trouver ces données L’événement peut être déduit du suivi des mises à jour importantes de l’enregistrement de la facture dans AP_INVOICES_ALL, après sa validation ou sa soumission pour approbation. Il faut disposer de l’horodatage LAST_UPDATE_DATE et des données de la piste d’audit. Données à recueillir Déduit de la comparaison de LAST_UPDATE_DATE après un rejet ou une mise en attente. Type d’événement inferred
	Facture mise en attente	Activité générique désignant toute mise en attente d’une facture qui l’empêche de passer au paiement. Elle peut être due à différents motifs, comme un problème de rapprochement, des fonds insuffisants ou une intervention manuelle.
Pourquoi est-ce important ? Cette activité influe directement sur le temps de cycle et peut entraîner des retards de paiement. L’analyse des mises en attente aide à repérer et à résoudre les problèmes systémiques du processus, et alimente l’analyse des « Tendances des blocages de paiement ». Où trouver ces données L’événement est enregistré explicitement dans la table AP_HOLDS_ALL. Chaque ligne correspond à une mise en attente, avec une date de création (HOLD_DATE) et un motif. Données à recueillir Création d’un enregistrement dans la table AP_HOLDS_ALL. Type d’événement explicit
	Facture rejetée	Un approbateur a rejeté la facture au cours du flux de travail d’approbation. Cette décision renvoie généralement la facture pour correction ou annulation et déclenche une boucle de reprise.
Pourquoi est-ce important ? Ce résultat négatif est une cause importante de reprises et d’allongement du temps de cycle. Le suivi des rejets aide à repérer les problèmes de qualité des factures ou de conformité aux bons de commande. Où trouver ces données Déduit du passage de APPROVAL_STATUS à « Rejected » dans la table AP_INVOICES_ALL. L’historique du flux de travail indique qui a rejeté la facture et à quel moment. Données à recueillir Déduit du changement de statut de AP_INVOICES_ALL.APPROVAL_STATUS à « Rejected ». Type d’événement inferred
	Facture validée	Indique que la facture a passé les contrôles du système portant sur 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 la facture.
Pourquoi est-ce important ? Cette étape importante précède le rapprochement et l’approbation. Un retard à ce stade peut révéler des problèmes de qualité des données de facturation ou de configuration du système. Où trouver ces données 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é. Données à recueillir Déduit d’une modification du champ AP_INVOICES_ALL.VALIDATION_STATUS. Type d’événement inferred
	Mise en attente levée pour la facture	Cet événement marque la levée d’une mise en attente précédemment appliquée à la facture. Un utilisateur ou un processus automatisé supprime le blocage et permet à la facture de poursuivre son cycle.
Pourquoi est-ce important ? Le délai entre la mise en attente et sa levée mesure l’efficacité du traitement des exceptions. Il contribue au calcul du KPI « Temps moyen de résolution des exceptions ». Où trouver ces données L’événement est enregistré dans la table AP_HOLDS_ALL. Lorsqu’une mise en attente est levée, les champs RELEASE_LOOKUP_CODE et RELEASE_REASON sont renseignés, ainsi que LAST_UPDATE_DATE. Données à recueillir Mise à jour d’un enregistrement dans la table AP_HOLDS_ALL pour indiquer que la mise en attente a été levée. Type d’événement explicit
	Paiement créé	Le système a généré l’instruction de paiement de la facture. Il peut s’agir de la création d’un chèque, d’un fichier de virement électronique (EFT) ou d’un autre moyen de paiement.
Pourquoi est-ce important ? À cette étape, l’organisation affecte les fonds au paiement. C’est une étape importante juste avant le débit du compte bancaire. Où trouver ces données L’événement est enregistré dans la table AP_CHECKS_ALL, qui contient les informations sur tous les paiements. CHECK_DATE indique la date de création du document de paiement. Données à recueillir 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 paiement. Elle est alors en attente de règlement.
Pourquoi est-ce 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 d’escomptes pour paiement anticipé. Où trouver ces données L’événement est enregistré dans la table AP_INVOICE_PAYMENTS_ALL lorsqu’un paiement est créé, mais pas encore confirmé comme effectué. Il peut également figurer dans des tables de lots de paiement, comme IBY_PAYMENT_PROCESS_REQUESTS. Données à recueillir 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 extraire vos données d’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).
Ouvrez BI Cloud Connector : dans le menu de navigation principal, sélectionnez Tools > BI Cloud Connector. La console BICC s’ouvre.
Sélectionnez une offre : dans la console BICC, choisissez l’offre correspondant à vos données financières, généralement nommée « Financials ».
Configurez le stockage externe : ouvrez la section « Configure External Storage ». Configurez la connexion à l’espace de stockage cloud dans lequel seront déposés les fichiers CSV extraits, par exemple Oracle Cloud Infrastructure (OCI) Object Storage.
Activez les offres à extraire : ouvrez la section « Manage Offerings and PVOs » ou une section équivalente. Sélectionnez l’offre « Financials » et activez-la pour l’extraction.
Sélectionnez les objets de vue publique (PVO) : recherchez et sélectionnez les PVO nécessaires au processus de traitement des factures. Les principaux PVO sont : FscmTopModelAM.FinApInvQuickInvoicesAM.InvoiceHeaderPVO, FscmTopModelAM.FinApInvHoldAM.InvoiceHoldPVO, FscmTopModelAM.FinApInvSharedAM.InvoiceApprovalHistoryPVO et FscmTopModelAM.FinApPmtsInvPmtsAM.PaymentPVO.
Planifiez le travail d’extraction : ouvrez « Manage Extract Schedules ». Créez un travail, donnez-lui un nom explicite et sélectionnez tous les PVO activés à l’étape précédente. Planifiez son exécution. Pour le chargement initial, indiquez la période historique souhaitée. Pour les exécutions suivantes, configurez des extractions incrémentielles à partir de LastUpdateDate.
Suivez l’extraction et récupérez les données : surveillez l’avancement du travail dans la console BICC. Une fois l’exécution terminée, ouvrez l’emplacement de stockage cloud configuré. Les données extraites s’y trouvent sous forme 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, comme un entrepôt ou un lac de données, où vous pourrez exécuter des requêtes SQL. Chargez chaque fichier CSV dans une table distincte.
Transformez les données en journal d’événements : exécutez la requête SQL fournie sur les tables de votre zone de préparation. Elle rassemble les données des différentes tables pour créer une table unique de journal d’événements.
Exportez les données pour ProcessMind : exportez le résultat de la requête SQL dans un seul fichier CSV. Vérifiez que les en-têtes de colonnes correspondent aux attributs requis (InvoiceNumber, ActivityName, EventTime, etc.) avant d’importer le fichier dans ProcessMind.

Configuration

Principaux objets de vue publique (PVO) : l’extraction s’appuie sur plusieurs PVO essentiels de l’offre Financials. Vous devez au minimum inclure :
- FscmTopModelAM.FinApInvQuickInvoicesAM.InvoiceHeaderPVO : données principales des factures, événements de création, de validation et d’annulation.
- FscmTopModelAM.FinApInvHoldAM.InvoiceHoldPVO : tous les événements de mise en attente et de libération des factures.
- FscmTopModelAM.FinApInvSharedAM.InvoiceApprovalHistoryPVO : étapes détaillées du flux d’approbation, notamment la soumission, l’approbation et le rejet.
- FscmTopModelAM.FinApPmtsInvPmtsAM.PaymentPVO : événements de création et d’exécution des paiements.
- FscmTopModelAM.FinApInvPmtsAM.InstallmentPVO : identification de la date à laquelle le paiement d’une facture est planifié.
Extractions incrémentielles : pour assurer un suivi continu, configurez le travail BICC afin qu’il effectue des extractions incrémentielles. Utilisez la colonne LastUpdateDate, disponible dans la plupart des PVO, comme critère de filtrage pour extraire uniquement les enregistrements nouveaux ou modifiés depuis la dernière exécution.
Filtrage par période : pour le chargement initial des données historiques, il est recommandé d’extraire une période raisonnable, par exemple les 6 à 12 derniers mois. Vous pouvez appliquer un filtre général dans la planification du travail BICC pour 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 un attribut équivalent dans la configuration du travail BICC. Cette étape est particulièrement importante dans les environnements multi-entités pour maîtriser le volume de données.
Prérequis : votre compte utilisateur doit disposer des rôles nécessaires, principalement BICC Administrator (BICC_ADMIN) et Functional Setup User (FSM_IMPLEMENTATION_CONSULTANT), pour configurer et exécuter les travaux d’extraction. Vous devez également avoir accès à un emplacement de stockage cloud configuré, tel que OCI Object Storage ou UCM.

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. Ouvrez l’outil Reports and Analytics depuis le menu Navigator, puis sélectionnez Tools et cliquez sur Reports and Analytics.
Ouvrez le catalogue : dans l’espace de travail Reports and Analytics, cliquez sur Browse Catalog pour accéder à l’interface Oracle BI Publisher.
Créez un modèle de données : dans le catalogue BI Publisher, ouvrez un dossier adapté, par exemple Shared Folders > Custom. Cliquez sur le menu déroulant New, puis 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 fenêtre New Data Set, indiquez un nom, par exemple 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 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 renseignera ces 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 dans votre dossier personnalisé. Pour afficher des données d’exemple, cliquez sur l’onglet « Data » et renseignez les paramètres créés.
Créez un rapport : retournez au catalogue, cliquez sur le menu déroulant New, puis sélectionnez Report. Dans l’assistant de création, choisissez l’option « Use Data Model » et sélectionnez le modèle de données que vous venez d’enregistrer.
Configurez la mise en page et le format de sortie : une simple mise en page en tableau suffit dans l’éditeur de rapport. L’étape la plus importante consiste à définir 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 activé. Le fichier obtenu ne comportera ainsi aucun formatage superflu.
Planifiez le rapport : enregistrez le rapport. Vous pouvez l’exécuter à la demande ou, pour de meilleures performances, le planifier en dehors des heures de pointe. Vous pouvez configurer la planification pour envoyer le fichier CSV vers une destination précise, telle que le serveur Universal Content Management (UCM), où vous pourrez le récupérer pour l’importer.
Exportez et préparez les données : une fois le travail de génération du rapport terminé, téléchargez le fichier CSV obtenu. Avant de l’importer dans l’outil de Process Mining, vérifiez que les en-têtes de colonnes correspondent aux attributs requis (InvoiceNumber, ActivityName, EventTime, etc.).

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 accessible via la source de données JNDI ApplicationDB_FSCM dans BI Publisher.
Paramètres : configurez le modèle de données avec les paramètres suivants pour 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 (code société) servant à filtrer les données. Utilisez un caractère générique comme « % » pour extraire les données de toutes les unités opérationnelles.
Période : pour la première extraction, il est recommandé de sélectionner une période de 3 à 6 mois. Vous disposerez ainsi d’un jeu de données représentatif tout en maîtrisant les performances de l’extraction.
Performances : l’extraction de données sur une longue période ou pour toutes les unités opérationnelles en une seule fois peut mobiliser beaucoup de ressources et entraîner des délais d’attente dépassés. Il est recommandé de répartir les extractions volumineuses en 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 à 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.

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, ouvrez la Security Console. Créez une application confidentielle pour obtenir l’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, par exemple 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 de remplacement en haut du script : CLIENT_ID, CLIENT_SECRET, TOKEN_URL, FUSION_HOST, START_DATE et END_DATE. La variable FUSION_HOST doit contenir 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 préciser la période couverte par l’extraction. Pour tester le script et vérifier le résultat, il est recommandé de commencer par une période courte, par exemple un mois.
Exécutez le script : depuis la ligne de commande ou le terminal, accédez au répertoire du script et saisissez python extract_fusion_invoices.py. Le script s’authentifie, récupère les données et affiche l’avancement dans la console.
Authentification : le script envoie d’abord une requête avec 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 des données et pagination : le script interroge le point de terminaison REST invoices pour 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 de nouvelles requêtes 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 connaître les mises en attente et les libérations, ainsi que le point de terminaison /payments, filtré par numéro de facture, pour récupérer les données de paiement.
Création du journal d’événements : le script traite les données JSON brutes de l’API. Il vérifie les dates, les statuts et les enregistrements enfants pour 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 « Facture annulée ».
Vérifiez le résultat : à la fin de l’exécution, le script crée un fichier nommé invoice_event_log.csv dans le même répertoire. Ouvrez-le dans un tableur pour vérifier les données. Assurez-vous que toutes les colonnes requises (InvoiceNumber, ActivityName, EventTime) et les attributs recommandés sont présents.
Préparez l’importation : vérifiez que les en-têtes de colonnes du fichier CSV correspondent aux noms des attributs requis. En général, aucun autre formatage n’est nécessaire. Le fichier est prêt à être importé dans votre outil de Process Mining.

Configuration

Identifiants d’authentification : vous devez disposer d’un Client ID et d’un Client Secret provenant d’une application confidentielle enregistrée dans la Security Console d’Oracle Fusion. Vous devez également fournir le Token URL de votre domaine d’identité.
URL de l’hôte API : la variable FUSION_HOST doit contenir 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 déterminent 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 interroge principalement 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 détermine 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 augmente la mémoire utilisée par requête. Une valeur plus faible peut être nécessaire en cas de délais d’attente dépassés.
Autorisations requises : le compte utilisateur associé aux identifiants API doit disposer d’un accès en lecture aux factures fournisseurs, aux mises en attente de factures, aux paiements et aux informations sur les fournisseurs. Le rôle Payables Invoice Inquiry Duty accorde généralement les autorisations nécessaires.

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 le traitement de vos factures en préparant vos données à l’aide de ce modèle. Faites apparaître des pistes d’amélioration et gagnez en efficacité 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 et réduisez les temps de cycle de 30 %

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

Démarrez l’essai gratuit

Aucune carte bancaire requise. Obtenez 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

Attributs du processus Purchase to Pay, traitement des factures

Activités du processus Purchase to Pay, traitement des factures

Guides d’extraction

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

Étapes

Configuration

Exemple de requête sql

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

Étapes

Configuration

Exemple de requête sql

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

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant le traitement de vos factures P2P et réduisez les temps de cycle de 30 %

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

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

Attributs du processus Purchase to Pay, traitement des factures

Activités du processus Purchase to Pay, traitement des factures

Guides d’extraction

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

Étapes

Configuration

Exemple de requête sql

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

Étapes

Configuration

Exemple de requête sql

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

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant le traitement de vos factures P2P et réduisez les temps de cycle de 30 %

Prêt à commencer ?