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

Oracle Fusion Financials
Votre modèle de données Purchase to Pay - Purchase Order

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

Ce modèle fournit une feuille de route claire pour recueillir les données nécessaires à l’analyse de votre processus Purchase to Pay - Purchase Order. Il présente les attributs de données essentiels, les principales activités à suivre et des indications pratiques pour extraire ces informations. Utilisez-le pour vous assurer de recueillir tous les éléments nécessaires à un Process Mining efficace.
  • Attributs recommandés pour une collecte complète des données
  • Principales activités du processus à suivre et à analyser
  • Guide d’extraction étape par étape 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.

Purchase to Pay - Purchase Order : attributs

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus Purchase to Pay - Purchase Order.
3 Obligatoire 7 Recommandé 11 Facultatif
Nom Description
Activité
ActivityName
Nom d’un événement ou d’une étape métier précis survenu au cours du cycle de vie du bon de commande.
Description

Cet attribut décrit une tâche précise ou un changement de statut dans le processus, comme « Purchase Order Created » ou « Goods Received ». Ces activités constituent la séquence d’événements qui forme le flux du processus.

L’analyse de leur séquence et de leur chronologie est au cœur du Process Mining. Elle permet de visualiser la cartographie du processus, d’identifier les goulots d’étranglement, de détecter les écarts par rapport à la procédure standard et de mesurer la durée de certaines étapes.

Pourquoi c’est important

Les activités sont les éléments constitutifs de la cartographie du processus. Leur suivi permet de visualiser et d’analyser le flux du processus, les goulots d’étranglement et les écarts.

Où les obtenir

Dérivé des changements de statut dans des tables telles que PO_HEADERS_ALL et PO_ACTION_HISTORY, ou de tables de transactions spécifiques comme RCV_TRANSACTIONS pour les réceptions de marchandises.

Exemples
Bon de commande crééBon de commande approuvéMarchandises reçues
Bon de commande
PurchaseOrder
Identifiant unique du document de bon de commande, utilisé comme Case ID principal pour suivre le cycle de vie de l’approvisionnement.
Description

Le numéro du bon de commande est l’identifiant central qui relie toutes les activités associées, de sa création à sa clôture définitive. Il permet d’analyser de bout en bout un cas d’approvisionnement donné.

Dans le Process Mining, chaque numéro de bon de commande unique représente une instance du processus. L’analyse des données regroupées selon cet identifiant permet de comprendre les variations du processus, les délais de cycle et la conformité de chaque commande.

Pourquoi c’est important

Il s’agit du Case ID essentiel qui relie tous les événements associés et permet de reconstituer et d’analyser l’ensemble du cycle de vie du bon de commande.

Où les obtenir

Oracle Fusion Cloud SCM, module Procurement, table PO_HEADERS_ALL, colonne SEGMENT1.

Exemples
100234510023461002347
Heure de début
EventTime
Horodatage indiquant le moment où une activité ou un événement précis s’est produit.
Description

Cet attribut enregistre la date et l’heure exactes de chaque activité du processus. Il est indispensable pour classer les événements dans l’ordre chronologique et réaliser toutes les analyses temporelles.

Dans le Process Mining, l’heure de début sert à construire l’Event Log, à calculer les délais de cycle entre les activités, à mesurer les temps d’attente et à analyser la performance du processus sur différentes périodes. Elle est essentielle aux Dashboards consacrés aux délais de cycle et à la performance.

Pourquoi c’est important

Cet horodatage est essentiel pour ordonner correctement les événements et calculer toutes les métriques fondées sur la durée, notamment les délais de cycle et les goulots d’étranglement.

Où les obtenir

Champs d’horodatage tels que CREATION_DATE et LAST_UPDATE_DATE provenant de différentes tables, notamment PO_HEADERS_ALL, PO_ACTION_HISTORY et RCV_SHIPMENT_LINES.

Exemples
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
Date de livraison demandée
RequestedDeliveryDate
Date à laquelle le demandeur souhaite que les biens ou services soient livrés.
Description

Cette date est indiquée sur la ligne du bon de commande et communique au fournisseur le délai de livraison souhaité. Elle sert de référence pour mesurer la performance des livraisons dans les délais.

Cet attribut est essentiel au calcul du KPI « Taux de livraison dans les délais ». En comparant la date réelle de réception des marchandises à la date de livraison demandée, les organisations peuvent mesurer et suivre quantitativement la fiabilité des fournisseurs et repérer les retards systémiques dans la chaîne d’approvisionnement.

Pourquoi c’est important

Sert de référence pour mesurer la performance des livraisons dans les délais, un KPI important pour évaluer la fiabilité des fournisseurs et l’efficacité de la chaîne d’approvisionnement.

Où les obtenir

Situé au niveau de l’emplacement de ligne, dans la table PO_LINE_LOCATIONS_ALL, colonne NEED_BY_DATE.

Exemples
2023-05-202023-06-152023-07-01
Heure de fin
EndTime
Horodatage correspondant à la fin d’une activité. Pour les événements atomiques, il est souvent identique à l’heure de début.
Description

Pour les activités qui ont une durée, il indique l’heure d’achèvement. Pour les événements instantanés, il est généralement identique à l’heure de début. Il est indispensable pour calculer le temps de traitement de chaque activité.

La présence d’une heure de fin distincte permet d’analyser plus précisément la durée des activités, qui peut différer du temps d’attente entre deux activités. Vous pouvez ainsi distinguer le temps de travail effectif du temps d’inactivité et analyser la charge de travail et l’efficacité des ressources.

Pourquoi c’est important

Permet de calculer avec précision les temps de traitement des activités, ce qui est essentiel pour analyser l’efficacité des ressources et identifier les tâches les plus chronophages.

Où les obtenir

Peut être identique à l’heure de début pour les événements atomiques ou être déduite des horodatages des événements suivants. Pour certaines activités, un horodatage d’achèvement distinct peut être disponible.

Exemples
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
Montant total du bon de commande
PurchaseOrderTotalAmount
Valeur monétaire totale du bon de commande.
Description

Cet attribut représente le coût total de tous les articles du bon de commande dans la devise indiquée. Il s’agit d’un indicateur financier important pour comprendre la valeur des transactions qui traversent le processus.

L’analyse du montant total des bons de commande aide à hiérarchiser les initiatives d’amélioration. Par exemple, les commandes de montant élevé peuvent être soumises à un processus d’approbation plus strict. Elle permet également d’analyser l’incidence financière, notamment en calculant la valeur des bons de commande fréquemment modifiés ou retardés.

Pourquoi c’est important

Fournit un contexte financier au processus et permet d’analyser les commandes selon leur valeur monétaire, par exemple en se concentrant sur les commandes de montant élevé ou en évaluant l’incidence financière des retards.

Où les obtenir

Calculé en additionnant les montants de PO_LINES_ALL pour un en-tête de bon de commande donné, ou repris d’un total au niveau de l’en-tête lorsqu’il est disponible.

Exemples
5250.00120000.50750.99
Nom de l’approbateur
ApproverName
Nom de l’utilisateur ayant effectué une action d’approbation ou de rejet sur le bon de commande.
Description

Cet attribut identifie la personne responsable d’une étape d’approbation dans le flux de travail. Ces informations sont généralement stockées dans une table d’historique des actions ou dans une table de journal du flux de travail associée au bon de commande.

L’analyse des données par approbateur est essentielle pour les Dashboards « PO Approval Cycle Time Analysis » et « Approval Resource Workload ». Elle aide à identifier les approbateurs ou les groupes d’approbation qui constituent des goulots d’étranglement, permet d’évaluer équitablement la charge de travail et peut mettre en évidence des possibilités de délégation ou de refonte du processus.

Pourquoi c’est important

Identifie les personnes intervenant dans la chaîne d’approbation, afin d’analyser les goulots d’étranglement, la charge de travail et les délais de cycle par approbateur.

Où les obtenir

Utilisateur ayant effectué l’action, indiqué dans PO_ACTION_HISTORY.ACTION_PERFORMED_BY et associé à une table utilisateurs pour obtenir le nom complet.

Exemples
susan.managerdavid.directoremily.finance
Nom du fournisseur
VendorName
Nom du fournisseur auprès duquel les biens ou services sont achetés.
Description

Cet attribut identifie le fournisseur externe associé au bon de commande. Il s’agit d’une donnée de référence essentielle liée à l’en-tête du bon de commande.

L’analyse des fournisseurs constitue un volet important du Process Mining appliqué au processus P2P. En filtrant ou en segmentant les données par fournisseur, les entreprises peuvent analyser la « Vendor Delivery Performance », comparer les taux de livraison dans les délais et étudier le « Goods Return Rate » afin d’identifier les fournisseurs les plus ou les moins performants. Ces données sont essentielles à la gestion des relations fournisseurs et aux achats stratégiques.

Pourquoi c’est important

Essentiel à l’analyse de la performance des fournisseurs, cet attribut permet de comparer les délais de livraison, les taux de retour et la fiabilité globale des différents fournisseurs.

Où les obtenir

Relié de PO_HEADERS_ALL.VENDOR_ID à POZ_SUPPLIERS.VENDOR_NAME.

Exemples
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
Service
DepartmentName
Nom du service qui a initié le bon de commande ou qui en est responsable.
Description

Cet attribut précise l’unité organisationnelle, comme « Finance », « IT » ou « Manufacturing », associée à l’achat. Il sert à répartir les coûts et à produire des rapports organisationnels.

Dans le contexte du Process Mining, la segmentation du processus par service est essentielle pour comparer les performances, identifier les goulots d’étranglement propres à chaque service et comprendre les variations d’exécution au sein de l’organisation. Elle alimente directement des Dashboards tels que « PO Approval Cycle Time Analysis » et « Purchase Order Modification Trends ».

Pourquoi c’est important

Permet de filtrer et de comparer la performance du processus entre différentes unités opérationnelles, afin de révéler les problèmes propres à un service ou les bonnes pratiques.

Où les obtenir

Dérivé des informations de centre de coûts figurant dans des tables telles que PO_DISTRIBUTIONS_ALL, qui est reliée aux données de référence des services.

Exemples
Opérations informatiquesMarketingRecherche et développement
Utilisateur
UserName
Identifiant ou nom de l’utilisateur ayant exécuté l’activité.
Description

Cet attribut identifie le collaborateur ou l’utilisateur système responsable d’un événement donné, comme la création d’une demande d’achat, l’approbation d’un bon de commande ou l’enregistrement d’une réception de marchandises. Il provient généralement de champs tels que « Created By » ou « Last Updated By ».

L’analyse du processus par utilisateur permet de comprendre la répartition de la charge de travail, d’évaluer les performances individuelles et d’identifier les besoins de formation. Elle est indispensable au Dashboard « Approval Resource Workload » et à l’analyse des problèmes de conformité liés aux actions des utilisateurs.

Pourquoi c’est important

Attribue les actions des utilisateurs à des personnes précises, ce qui permet d’analyser la charge de travail, d’évaluer les performances et d’identifier les possibilités de formation.

Où les obtenir

Effectuez une jointure avec les tables utilisateurs à partir des identifiants figurant dans des champs tels que CREATED_BY ou LAST_UPDATED_BY, notamment dans les tables PO_HEADERS_ALL et PO_ACTION_HISTORY.

Exemples
john.doejane.smithsystem.batch
Catégorie d’achat
PurchaseCategory
Classification des biens ou services achetés, par exemple « Matériel informatique » ou « Fournitures de bureau ».
Description

Cet attribut classe les articles du bon de commande dans une hiérarchie d’approvisionnement. Cette classification est utilisée pour l’analyse des dépenses et la gestion des fournisseurs.

Dans le cadre du Process Mining, la segmentation du processus par catégorie d’achat peut révéler des comportements ou des niveaux de performance différents. Par exemple, le processus d’approbation des dépenses d’investissement peut être plus long que celui des fournitures d’exploitation. Cet attribut contribue directement au Dashboard « Taux et motifs de retour des marchandises », en permettant d’analyser les catégories les plus souvent retournées.

Pourquoi c’est important

Permet d’analyser le processus par type de dépense et de révéler les différents parcours, goulots d’étranglement ou taux de retour associés aux catégories de biens.

Où les obtenir

Lien établi de PO_LINES_ALL.CATEGORY_ID vers la vue EGP_CATEGORIES_VL.

Exemples
Matériel informatique.Ordinateurs portablesFournitures de bureau.PapeterieServices professionnels.Conseil
Conformité de l’approbation
IsApprovalCompliant
Indicateur précisant si le bon de commande a été approuvé avant son envoi au fournisseur.
Description

Il s’agit d’un attribut booléen calculé qui vérifie le respect d’un contrôle interne important : un bon de commande doit être approuvé avant d’être envoyé à un fournisseur. Il est défini sur true si l’activité « Purchase Order Approved » intervient avant l’activité « Purchase Order Sent to Vendor ».

Cet attribut est essentiel au Dashboard « Audit de conformité du processus des bons de commande » et au KPI « Taux de conformité des approbations des bons de commande ». Il permet d’identifier et de quantifier simplement les manquements à la conformité, de faire respecter les politiques d’approvisionnement et de réduire les risques liés aux dépenses non autorisées.

Pourquoi c’est important

Mesure directement le KPI « Taux de conformité des approbations des bons de commande » et met en évidence les violations importantes des contrôles internes, lorsque des commandes sont envoyées aux fournisseurs avant leur approbation.

Où les obtenir

Champ calculé. Défini sur « true » si l’horodatage de « Purchase Order Approved » est inférieur ou égal à celui de « Purchase Order Sent to Vendor ».

Exemples
truefalse
Demande d’achat
PurchaseRequisitionNumber
Identifiant de la demande d’achat qui a précédé et autorisé le bon de commande.
Description

La demande d’achat est le document interne utilisé pour demander l’achat de biens ou de services. Cet attribut relie le bon de commande à la demande à l’origine du processus.

L’inclusion du numéro de demande permet d’analyser le processus d’approvisionnement dans son ensemble, depuis la demande initiale et non uniquement à partir du bon de commande. Elle permet d’étudier le délai entre la demande et la commande, ainsi que l’influence des détails de la demande sur le processus ultérieur du bon de commande.

Pourquoi c’est important

Relie le bon de commande à la demande initiale et permet d’obtenir une vue complète du processus, de la demande au paiement.

Où les obtenir

Lien établi via la table PO_DISTRIBUTIONS_ALL, qui contient REQ_DISTRIBUTION_ID et permet de remonter jusqu’à la table POR_REQUISITION_LINES_ALL.

Exemples
PR-2023-05-001PR-2023-05-002PR-2023-05-003
Dernière mise à jour des données
LastDataUpdate
Horodatage correspondant à la dernière extraction ou actualisation des données depuis le système source.
Description

Cet attribut indique la fraîcheur des données analysées. Il enregistre la date et l’heure de la dernière extraction des données depuis Oracle Fusion Financials.

Ces informations sont indispensables pour comprendre l’actualité de l’analyse et des Dashboards. Elles précisent jusqu’à quelle date les analyses de processus sont à jour et permettent de savoir si les transactions les plus récentes sont incluses.

Pourquoi c’est important

Garantit la transparence sur la fraîcheur des données et permet aux utilisateurs de comprendre jusqu’à quelle date l’analyse du processus est à jour.

Où les obtenir

Il s’agit d’un horodatage généré et ajouté lors du processus d’extraction et de transformation des données (ETL).

Exemples
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Lieu de livraison
DeliveryLocation
Lieu physique ou adresse où les marchandises doivent être livrées.
Description

Cet attribut indique l’adresse de livraison des articles du bon de commande. Il constitue une information logistique importante.

Dans le cadre du Process Mining, l’analyse par lieu de livraison alimente le Dashboard « Efficacité du traitement des réceptions de marchandises ». Elle permet de déterminer si certains entrepôts ou sites traitent les réceptions plus lentement, ce qui peut révéler des problèmes de ressources ou de processus propres à certains lieux.

Pourquoi c’est important

Permet d’analyser la performance par zone géographique et d’identifier les goulots d’étranglement régionaux ou propres à certains sites dans le processus de réception des marchandises.

Où les obtenir

Lien établi de PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID vers la vue HR_LOCATIONS_ALL.

Exemples
Entrepôt principal, quai ABâtiment 3, réceptionBureau de San Francisco, 10e étage
Livraison en retard
IsLateDelivery
Indicateur précisant si la réception finale des marchandises a eu lieu après la date de livraison demandée.
Description

Cet attribut booléen calculé est défini sur true lorsque l’horodatage de l’activité « Goods Received » est postérieur à la valeur de l’attribut « Requested Delivery Date » pour un bon de commande donné.

Cet indicateur constitue la base du KPI « Taux de livraison dans les délais ». Il facilite la segmentation et l’analyse des commandes livrées en retard ou dans les délais, afin d’étudier les causes profondes des retards, qu’elles soient liées à certains fournisseurs, lieux ou catégories de produits.

Pourquoi c’est important

Contribue directement au KPI « Taux de livraison dans les délais » et permet d’analyser clairement la performance et la fiabilité des livraisons des fournisseurs.

Où les obtenir

Champ calculé. Défini sur « true » si l’horodatage de l’activité « Goods Received » est postérieur à l’attribut « RequestedDeliveryDate ».

Exemples
truefalse
Retouche effectuée
IsRework
Indicateur précisant si le bon de commande a été modifié après sa création initiale.
Description

Il s’agit d’un attribut booléen calculé, défini sur true lorsqu’un dossier de bon de commande contient une activité « Purchase Order Changed ». Il permet d’identifier rapidement les commandes ayant nécessité des corrections ou des modifications.

Cet indicateur simplifie le calcul du KPI « Taux de modification des bons de commande » et facilite le filtrage et l’analyse des commandes retravaillées. L’étude des caractéristiques de ces commandes, notamment des fournisseurs ou des services concernés, peut aider à déterminer les causes profondes des erreurs de données ou de l’évolution des besoins.

Pourquoi c’est important

Contribue directement au KPI « Taux de modification des bons de commande » et simplifie l’analyse de l’instabilité du processus en signalant toutes les commandes ayant subi des modifications.

Où les obtenir

Champ calculé. Défini sur « true » si le journal d’événements d’un dossier contient l’activité « Purchase Order Changed », sinon sur « false ».

Exemples
truefalse
Statut du bon de commande
PurchaseOrderStatus
Statut actuel du document de bon de commande.
Description

Cet attribut indique l’état actuel du bon de commande dans son cycle de vie, par exemple « Open », « Approved », « Finally Closed » ou « Canceled ». Il fournit une vue instantanée de l’avancement du bon de commande.

Le Process Mining s’intéresse principalement à la séquence des activités, mais le statut actuel est utile pour filtrer les cas. Vous pouvez, par exemple, limiter l’analyse aux bons de commande ouverts afin de comprendre le portefeuille en cours, ou aux bons de commande clôturés pour analyser les instances terminées. Cet attribut est essentiel au Dashboard « Purchase Order Flow & Status ».

Pourquoi c’est important

Fournit une vue instantanée de l’état d’un bon de commande et permet de filtrer l’analyse sur les commandes actives, terminées ou annulées.

Où les obtenir

Oracle Fusion Cloud SCM, table PO_HEADERS_ALL, colonnes AUTHORIZATION_STATUS ou DOCUMENT_STATUS.

Exemples
OUVERTAPPROUVÉDÉFINITIVEMENT_CLÔTURÉANNULÉ
Système source
SourceSystem
Système d’information à partir duquel ces données ont été extraites.
Description

Cet attribut identifie l’origine des données, ce qui est particulièrement utile dans les environnements comprenant plusieurs systèmes intégrés. Pour ce processus, sa valeur serait généralement « Oracle Fusion Financials ».

Bien qu’il s’agisse souvent d’une valeur statique pour un jeu de données donné, cet attribut est essentiel à la gouvernance des données, au dépannage et à la traçabilité des données. Dans les analyses combinant plusieurs sources, il permet de filtrer et de segmenter les données selon leur système d’origine.

Pourquoi c’est important

Identifie l’origine des données, un élément essentiel pour la gouvernance des données, le contexte d’analyse et l’intégration avec d’autres systèmes.

Où les obtenir

Il s’agit généralement d’une valeur constante définie et ajoutée lors du processus d’extraction et de transformation des données (ETL).

Exemples
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
Type de bon de commande
PurchaseOrderType
Type de bon de commande, par exemple « Standard », « Blanket » ou « Contract ».
Description

Cet attribut classe le bon de commande selon son objectif d’approvisionnement. Les différents types de bons de commande suivent souvent des règles de processus et des cycles de vie distincts.

Un bon de commande « Standard » correspond à un achat ponctuel, tandis qu’un bon de commande « Blanket » constitue un accord à plus long terme avec un fournisseur. L’analyse du processus par type de bon de commande offre une vision plus précise de la performance, car comparer le délai de cycle d’un bon de commande standard à celui d’un accord Blanket serait trompeur. Elle permet de comparer des situations réellement comparables.

Pourquoi c’est important

Différencie les différents scénarios d’approvisionnement et permet de comparer plus précisément la performance de processus similaires, à périmètre comparable.

Où les obtenir

Oracle Fusion Cloud SCM, table PO_HEADERS_ALL, colonne TYPE_LOOKUP_CODE.

Exemples
STANDARDFORFAITAIRECONTRAT
Unité opérationnelle
BusinessUnitName
Unité opérationnelle précise de l’organisation qui effectue l’achat.
Description

L’unité opérationnelle représente une entité distincte au sein de l’entreprise, souvent dotée de son propre grand livre et de son propre reporting financier. Dans Oracle Fusion, elle constitue un mécanisme principal de séparation des données.

L’analyse de la performance des processus par unité opérationnelle est essentielle dans les grandes entreprises internationales. Elle permet de comparer l’efficacité des achats, la conformité et les coûts entre les différentes composantes de l’organisation, tout en mettant en évidence les bonnes pratiques et les domaines à améliorer.

Pourquoi c’est important

Essentiel pour les grandes organisations qui souhaitent comparer l’efficacité des processus et la conformité entre différentes divisions opérationnelles.

Où les obtenir

Le contexte de l’unité opérationnelle se trouve généralement dans l’en-tête du bon de commande, dans PO_HEADERS_ALL.PRC_BU_ID, qui est lié à la vue FUN_ALL_BUSINESS_UNITS_V.

Exemples
Unité opérationnelle des États-UnisVision EMEAServices APAC
Obligatoire Recommandé Facultatif

Purchase to Pay - Purchase Order : activités

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour découvrir précisément votre processus Purchase to Pay - Purchase Order.
6 Recommandé 10 Facultatif
Activité Description
Bon de commande annulé
Le bon de commande a été annulé définitivement et aucune autre transaction n’est attendue. Il s’agit d’une action explicite qui modifie le statut final du document.
Pourquoi c’est important

Cette activité représente une issue défavorable du processus. L’analyse des annulations peut révéler des problèmes tels que des commandes en double, des changements budgétaires ou une évolution des exigences du projet.

Où les obtenir

Cette action est enregistrée dans la table PO_ACTION_HISTORY avec un ACTION_CODE égal à 'CANCEL', et le statut du bon de commande dans PO_HEADERS_ALL est mis à jour en conséquence.

Collecte

Filtrez PO_ACTION_HISTORY avec ACTION_CODE = 'CANCEL'.

Type d’événement explicit
Bon de commande approuvé
Le bon de commande a reçu toutes les approbations nécessaires et peut désormais être envoyé au fournisseur. Il s’agit d’une étape importante, explicitement enregistrée dans l’historique des actions du document.
Pourquoi c’est important

Cette étape importante conditionne l’envoi du bon de commande au fournisseur. Elle est essentielle pour mesurer les délais d’approbation et vérifier le respect des politiques de dépenses.

Où les obtenir

Cet événement est enregistré dans la table PO_ACTION_HISTORY, généralement avec un ACTION_CODE égal à 'APPROVE', ou lorsque le statut du document dans PO_HEADERS_ALL passe à un statut approuvé.

Collecte

Filtrez PO_ACTION_HISTORY sur l’action finale 'APPROVE'.

Type d’événement explicit
Bon de commande clôturé définitivement
Le bon de commande est considéré comme terminé : il a été entièrement réceptionné et/ou facturé, et aucune autre activité n’est prévue. Il s’agit d’une action explicite qui attribue un statut final au bon de commande.
Pourquoi c’est important

Cette activité marque l’achèvement réussi du cycle de vie du bon de commande. Il s’agit de l’issue positive principale du processus. Son suivi est essentiel pour mesurer le débit global du processus et les taux d’achèvement.

Où les obtenir

Cet événement est enregistré dans la table PO_ACTION_HISTORY avec un ACTION_CODE égal à 'FINALLY CLOSE'. Le statut du bon de commande dans PO_HEADERS_ALL est également mis à jour sur « Finally Closed ».

Collecte

Filtrez PO_ACTION_HISTORY avec ACTION_CODE = 'FINALLY CLOSE'.

Type d’événement explicit
Bon de commande créé
Il s’agit du début officiel du cycle de vie du bon de commande. Un document est généré avec le statut « brouillon » ou « incomplet ». Le système enregistre cet événement au moyen de l’horodatage de création du nouvel enregistrement d’en-tête du bon de commande.
Pourquoi c’est important

En tant qu’événement de début principal du cas de bon de commande, cette activité est fondamentale pour tous les calculs de durée du cycle. Elle fournit le point de référence nécessaire pour mesurer l’efficacité des étapes suivantes, comme l’approbation et la communication avec le fournisseur.

Où les obtenir

Il s’agit d’un événement explicite fondé sur le champ CREATION_DATE de la table PO_HEADERS_ALL pour un identifiant de bon de commande donné (PO_HEADER_ID).

Collecte

Utilisez l’horodatage de création de la table PO_HEADERS_ALL.

Type d’événement explicit
Bon de commande envoyé au fournisseur
Le bon de commande approuvé est officiellement communiqué au fournisseur, par exemple par e-mail ou via EDI. Cet événement est souvent déduit d’un changement de statut ou d’un horodatage figurant dans l’enregistrement de communication du bon de commande.
Pourquoi c’est important

Cette étape marque le début du délai fournisseur. Elle constitue un point de référence important pour mesurer la performance du fournisseur, de l’accusé de réception à la livraison finale.

Où les obtenir

Cet événement peut être déduit du passage du statut du document à « Open » et du renseignement d’une date de communication. Le champ concerné est souvent PO_HEADERS_ALL.communicated_date ou un statut associé.

Collecte

Déduisez l’événement de l’horodatage correspondant à la mise à jour du statut de communication du bon de commande sur « Communicated ».

Type d’événement inferred
Marchandises reçues
Les marchandises ont été réceptionnées physiquement, comptées et enregistrées au regard du bon de commande. Il s’agit d’un événement transactionnel qui met à jour les stocks et le statut du bon de commande.
Pourquoi c’est important

Cette étape est importante pour mesurer la performance du fournisseur en matière de livraison dans les délais et le délai global. Elle déclenche également des activités ultérieures, comme le contrôle qualité et le rapprochement avec la facture.

Où les obtenir

Il s’agit d’un événement explicite enregistré dans la table RCV_TRANSACTIONS. La transaction concernée est identifiée par une valeur TRANSACTION_TYPE égale à 'RECEIVE'.

Collecte

Utilisez TRANSACTION_DATE dans RCV_TRANSACTIONS lorsque TRANSACTION_TYPE est égal à 'RECEIVE'.

Type d’événement explicit
Bon de commande accusé réception
Le fournisseur a confirmé la réception du bon de commande et l’acceptation de ses conditions. Cet événement est souvent saisi manuellement par le service des achats à partir des échanges avec le fournisseur, ou enregistré au moyen d’un accusé de réception électronique.
Pourquoi c’est important

L’accusé de réception du fournisseur confirme que la commande a bien été reçue et qu’elle est en cours de traitement. Son suivi facilite la gestion des échanges avec le fournisseur et permet d’identifier rapidement les problèmes susceptibles d’affecter l’exécution de la commande.

Où les obtenir

Cet événement est généralement déduit d’une modification des champs de statut d’accusé de réception dans l’en-tête ou les lignes du bon de commande, par exemple lorsque PO_HEADERS_ALL.acceptance_status passe à « Accepted ».

Collecte

Déduisez l’événement des mises à jour des champs de statut d’accusé de réception du bon de commande.

Type d’événement inferred
Bon de commande modifié
Une modification a été apportée au bon de commande après son approbation initiale, par exemple concernant la quantité, le prix ou la date de livraison. Oracle Fusion enregistre cette modification en créant une nouvelle révision du document.
Pourquoi c’est important

Les modifications d’un bon de commande constituent des reprises et peuvent révéler des problèmes de précision de la commande initiale ou une évolution des besoins de l’entreprise. L’analyse de leur fréquence et de leur nature permet d’identifier des possibilités d’amélioration de l’efficacité du processus.

Où les obtenir

Cet événement est explicitement enregistré lorsqu’une nouvelle révision du document est créée. Il peut être identifié par l’incrémentation du champ REVISION_NUM dans la table PO_HEADERS_ALL.

Collecte

Identifiez chaque cas où la valeur de REVISION_NUM augmente pour un PO_HEADER_ID donné.

Type d’événement explicit
Bon de commande rejeté
Un approbateur a rejeté le bon de commande et le renvoie à son créateur pour révision. Il s’agit d’un événement explicite enregistré dans l’historique des actions, qui signale une rupture dans le déroulement standard du processus.
Pourquoi c’est important

Les rejets entraînent des reprises et des retards. Le suivi de cette activité permet d’identifier les motifs fréquents de rejet, les besoins de formation ou les exigences d’approbation qui manquent de clarté.

Où les obtenir

Cette action est enregistrée dans la table PO_ACTION_HISTORY avec un ACTION_CODE égal à 'REJECT' pour le PO_HEADER_ID correspondant.

Collecte

Filtrez PO_ACTION_HISTORY avec ACTION_CODE = 'REJECT'.

Type d’événement explicit
Bon de commande soumis
Le bon de commande créé est soumis au flux d’approbation. Oracle Fusion consigne explicitement cette action, avec l’utilisateur et l’horodatage de l’événement de soumission.
Pourquoi c’est important

Cette activité marque le début du cycle d’approbation. L’analyse du délai entre la soumission et l’approbation est essentielle pour repérer les goulots d’étranglement du processus de validation interne.

Où les obtenir

Cette action est enregistrée dans la table PO_ACTION_HISTORY avec un ACTION_CODE égal à 'SUBMIT' pour le PO_HEADER_ID correspondant.

Collecte

Filtrez PO_ACTION_HISTORY avec ACTION_CODE = 'SUBMIT'.

Type d’événement explicit
Contrôle qualité effectué
Les marchandises soumises à un contrôle qualité ont été inspectées, puis acceptées ou rejetées. Cette activité intervient après la réception initiale et est enregistrée comme une transaction distincte.
Pourquoi c’est important

Cette activité est essentielle à la gestion de la qualité. L’analyse de la durée des contrôles permet d’optimiser le processus de contrôle qualité et de réduire les retards avant la mise à disposition des marchandises.

Où les obtenir

Cet événement est enregistré dans la table RCV_TRANSACTIONS. Il est identifié par les transactions dont TRANSACTION_TYPE est égal à 'ACCEPT' ou 'REJECT' et qui suivent une transaction de réception.

Collecte

Utilisez TRANSACTION_DATE dans RCV_TRANSACTIONS lorsque TRANSACTION_TYPE est égal à 'ACCEPT' ou 'REJECT'.

Type d’événement explicit
Demande d’achat approuvée
La demande d’achat a été approuvée par l’autorité désignée, ce qui autorise le service des achats à créer un bon de commande. Cet événement est explicitement enregistré dans l’historique des actions de la demande d’achat.
Pourquoi c’est important

Cette étape marque la fin du processus d’approbation interne de la demande. Les retards à ce stade peuvent avoir une incidence directe sur l’ensemble du calendrier d’approvisionnement. Il est donc important d’en surveiller la durée.

Où les obtenir

Cet événement est enregistré dans l’historique des actions associé à la demande d’achat, généralement au moyen de tables de flux de travail ou de champs de statut d’approbation spécifiques du document de demande.

Collecte

Enregistré comme une action d’approbation dans l’historique du flux de travail du document de demande concerné.

Type d’événement explicit
Demande d’achat créée
Cette activité correspond à la création d’une demande d’achat, c’est-à-dire la demande officielle de biens ou de services qui précède un bon de commande. Elle est enregistrée lorsqu’une nouvelle entrée est créée dans la table d’en-tête des demandes d’achat d’Oracle Fusion.
Pourquoi c’est important

L’analyse de cette activité permet de mieux comprendre la phase d’expression de la demande. Le suivi du délai entre la demande d’achat et la création du bon de commande révèle les éventuels retards dans la conversion d’un besoin interne en commande d’approvisionnement.

Où les obtenir

Il s’agit d’un événement explicite enregistré lors de l’enregistrement d’une nouvelle demande d’achat. Il peut être identifié en suivant l’horodatage de création dans la table POR_REQUISITION_HEADERS_ALL.

Collecte

L’événement repose sur la date de création de l’enregistrement dans la table POR_REQUISITION_HEADERS_ALL.

Type d’événement explicit
Marchandises retournées au fournisseur
Les marchandises précédemment réceptionnées sont renvoyées au fournisseur, généralement en raison de défauts, de dommages ou d’une livraison incorrecte. Cet événement est enregistré comme une transaction de retour spécifique dans le module de réception.
Pourquoi c’est important

Le suivi des retours est essentiel pour évaluer la qualité du fournisseur et l’exactitude des commandes. Un taux de retour élevé pour un fournisseur peut révéler des problèmes récurrents qui doivent être traités.

Où les obtenir

Il s’agit d’un événement explicite enregistré dans la table RCV_TRANSACTIONS avec une valeur TRANSACTION_TYPE égale à 'RETURN TO VENDOR'.

Collecte

Utilisez TRANSACTION_DATE dans RCV_TRANSACTIONS lorsque TRANSACTION_TYPE est égal à 'RETURN TO VENDOR'.

Type d’événement explicit
Prestation de services confirmée
Pour les bons de commande portant sur des services, cette activité confirme que les services ont été fournis conformément à l’accord. Cette confirmation est souvent saisie manuellement ou au moyen d’une feuille de saisie des services.
Pourquoi c’est important

Il s’agit de l’équivalent d’une réception de marchandises pour les services et d’une étape indispensable avant le paiement d’une facture. Les retards dans la confirmation des services peuvent entraîner des paiements tardifs et détériorer les relations avec les fournisseurs.

Où les obtenir

Cet événement est généralement enregistré comme une réception associée à une ligne de service du bon de commande. Il peut faire intervenir des champs spécifiques ou des réceptions complexes permettant de suivre l’avancement ou l’achèvement des services.

Collecte

Identifiez les transactions de réception (RCV_TRANSACTIONS) associées aux lignes de bons de commande portant sur des services.

Type d’événement explicit
Réception de marchandises créée
Un document de réception est créé dans le système en préparation de l’arrivée physique des marchandises. Cette activité marque le début du processus interne de réception.
Pourquoi c’est important

Cette étape marque le passage des achats à la logistique. L’analyse du délai entre ce point et l’enregistrement final de la réception permet d’identifier les inefficacités dans l’entrepôt ou le service de réception.

Où les obtenir

Il s’agit d’un événement explicite, enregistré au moyen de l’horodatage de création d’un nouvel enregistrement dans la table RCV_SHIPMENT_HEADERS, associé au bon de commande.

Collecte

Utilisez la date de création de l’enregistrement correspondant dans RCV_SHIPMENT_HEADERS.

Type d’événement explicit
Recommandé Facultatif

Guides d’extraction

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

Prêt à commencer ?

Utilisez ce modèle pour simplifier la collecte de vos données et commencer à faire apparaître des analyses sur votre processus Purchase to Pay - Purchase Order. Commencez dès aujourd’hui à optimiser vos opérations.

Optimisez dès aujourd’hui votre processus Purchase to Pay - Purchase Order

Repérez facilement les goulots d’étranglement coûteux et réduisez le délai de cycle de 30 %.

Démarrer l’essai gratuit

Aucune carte bancaire requise, commencez à optimiser dès aujourd’hui.