Votre modèle de données Purchase to Pay, bons de commande

Oracle Fusion Financials
Votre modèle de données Purchase to Pay, bons de commande

Votre modèle de données Purchase to Pay, bons de commande

Ce modèle vous guide dans la collecte des données nécessaires à l’analyse de votre processus Purchase to Pay, bons de commande. Il présente les attributs de données essentiels, les principales activités à suivre et des conseils pratiques pour extraire ces informations. Utilisez-le pour recueillir tous les éléments nécessaires à une analyse efficace par Process Mining.
  • Attributs recommandés pour recueillir des données complètes
  • 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 ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs du processus Purchase to Pay, bons de commande

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, bons de commande.
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, par exemple « Bon de commande créé » ou « Marchandises reçues ». Ces activités forment la séquence d’événements qui constitue le flux du processus.

L’analyse de leur séquence et de leur durée est au cœur du Process Mining. Elle permet de visualiser le processus, de repérer 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 est-ce important ?

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

Où trouver ces données

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

Exemples
Commande d’achat crééeCommande d’achat approuvéeMarchandises reçues
Bon de commande
PurchaseOrder
Identifiant unique du document de bon de commande, utilisé comme ID de cas principal pour suivre le cycle de vie des achats.
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’achat donné.

En Process Mining, chaque numéro de bon de commande unique correspond à une instance du processus. L’analyse des données regroupées par cet identifiant permet de comprendre les variations du processus, les temps de cycle et la conformité de chaque commande.

Pourquoi est-ce important ?

Il s’agit de l’ID de cas 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ù trouver ces données

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 ordonner les événements chronologiquement et effectuer toutes les analyses temporelles.

En Process Mining, l’heure de début sert à constituer le journal d’événements, à calculer les temps de cycle entre les activités, à mesurer les temps d’attente et à analyser les performances du processus sur différentes périodes. Elle est essentielle aux Dashboards consacrés aux temps de cycle et aux performances.

Pourquoi est-ce important ?

Cet horodatage est essentiel pour ordonner correctement les événements et calculer toutes les mesures de durée, notamment les temps de cycle et les goulots d’étranglement.

Où trouver ces données

Champs d’horodatage tels que CREATION_DATE et LAST_UPDATE_DATE dans 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 recevoir les marchandises ou les services.
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 de l’indicateur clé de performance « 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 la fiabilité des fournisseurs et repérer les retards récurrents dans la chaîne d’approvisionnement.

Pourquoi est-ce important ?

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

Où trouver ces données

Se trouve au niveau de l’emplacement de la 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 du moment où une activité a été achevée. Pour les événements instantanés, il est souvent identique à l’heure de début.
Description

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

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. Cette distinction aide à séparer le temps de travail effectif du temps d’inactivité et à analyser la charge de travail et l’efficacité des ressources.

Pourquoi est-ce important ?

Permet de calculer précisément la durée de traitement des activités, un élément essentiel pour analyser l’efficacité des ressources et repérer les tâches qui prennent du temps.

Où trouver ces données

Peut être identique à l’heure de début pour les événements instantanés ou être déduit des horodatages des événements suivants. Certaines activités disposent d’un horodatage d’achèvement distinct.

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’une mesure financière importante pour comprendre la valeur des transactions qui suivent le processus.

L’analyse du montant total des bons de commande aide à définir les priorités d’amélioration du processus. Par exemple, les commandes de grande valeur peuvent suivre un circuit d’approbation plus strict. Elle permet également d’évaluer les conséquences financières, par exemple en calculant la valeur des bons de commande souvent modifiés ou retardés.

Pourquoi est-ce important ?

Apporte un éclairage financier sur le processus et permet d’analyser les commandes selon leur valeur, par exemple en se concentrant sur les commandes de grande valeur ou en évaluant les conséquences financières des retards.

Où trouver ces données

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

Exemples
5250.00120000.50750.99
Nom de l’approbateur
ApproverName
Nom de l’utilisateur qui a approuvé ou rejeté 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 un 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 aux Dashboards « Analyse du temps de cycle d’approbation des bons de commande » et « Charge de travail des ressources chargées des approbations ». Elle aide à repérer les approbateurs ou les groupes d’approbation qui constituent des goulots d’étranglement, à évaluer équitablement la charge de travail et à mettre en évidence des possibilités de délégation ou de réorganisation du processus.

Pourquoi est-ce important ?

Identifie les personnes qui interviennent dans le circuit d’approbation et permet d’analyser les goulots d’étranglement, la charge de travail et les temps de cycle par approbateur.

Où trouver ces données

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

Exemples
susan.managerdavid.directoremily.finance
Nom du fournisseur
VendorName
Nom du fournisseur auprès duquel les marchandises ou les 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 importante, liée à l’en-tête du bon de commande.

L’analyse des fournisseurs est un volet important du Process Mining des achats. En filtrant ou en segmentant les données par fournisseur, les entreprises peuvent analyser la « Performance des livraisons des fournisseurs », comparer les taux de livraison dans les délais et examiner le « Taux de retour des marchandises » afin de repérer les fournisseurs les plus et les moins performants. Ces données sont essentielles à la gestion des relations fournisseurs et aux décisions d’approvisionnement stratégique.

Pourquoi est-ce important ?

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

Où trouver ces données

Lien entre PO_HEADERS_ALL.VENDOR_ID et POZ_SUPPLIERS.VENDOR_NAME.

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

Cet attribut précise l’unité organisationnelle associée à l’achat, par exemple « Finance », « Informatique » ou « Production ». Il sert à répartir les coûts et à produire des rapports par entité.

En Process Mining, la segmentation du processus par service est importante pour comparer les performances, repérer les goulots d’étranglement propres à chaque service et comprendre les différences d’exécution au sein de l’organisation. Elle contribue directement aux Dashboards tels que « Analyse du temps de cycle d’approbation des bons de commande » et « Tendances des modifications des bons de commande ».

Pourquoi est-ce important ?

Permet de filtrer et de comparer les performances du processus entre différentes unités opérationnelles, afin de repérer les problèmes propres à certains services ou les bonnes pratiques.

Où trouver ces données

Déduit des informations sur les centres de coûts dans des tables comme PO_DISTRIBUTIONS_ALL, qui renvoie aux données de référence des services.

Exemples
Opérations informatiquesMarketingRecherche et développement
Utilisateur
UserName
Identifiant ou nom de la personne qui a effectué l’activité.
Description

Cet attribut identifie l’employé ou l’utilisateur système responsable d’un événement donné, par exemple 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 « Créé par » ou « Dernière mise à jour par ».

L’analyse du processus par utilisateur aide à comprendre la répartition de la charge de travail, les performances individuelles et les besoins de formation. Elle est essentielle au Dashboard « Charge de travail des ressources chargées des approbations » et à l’examen des problèmes de conformité liés aux actions des utilisateurs.

Pourquoi est-ce important ?

Associe les actions à des personnes précises, ce qui permet d’analyser la charge de travail et les performances, ainsi que de repérer les besoins de formation.

Où trouver ces données

Effectuez une jointure avec les tables des utilisateurs à partir des identifiants présents dans des champs tels que CREATED_BY ou LAST_UPDATED_BY, dans des tables comme PO_HEADERS_ALL et PO_ACTION_HISTORY.

Exemples
john.doejane.smithsystem.batch
Approbation conforme
IsApprovalCompliant
Indique si le bon de commande a été approuvé avant son envoi au fournisseur.
Description

Cet attribut booléen calculé vérifie le respect d’un contrôle interne essentiel : un bon de commande doit être approuvé avant d’être envoyé à un fournisseur. Il prend la valeur true si l’activité « Purchase Order Approved » précède 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 de bons de commande ». Il permet de repérer et de quantifier facilement les manquements, afin de faire respecter les règles d’approvisionnement et de limiter les risques liés aux dépenses non autorisées.

Pourquoi est-ce important ?

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

Où trouver ces données

Champ calculé. Prend la valeur « true » si l’horodatage de « Purchase Order Approved » est antérieur ou égal à celui de « Purchase Order Sent to Vendor ».

Exemples
truefalse
Catégorie d’achat
PurchaseCategory
Classification des marchandises ou des services achetés, par exemple « Matériel informatique » ou « Fournitures de bureau ».
Description

Cet attribut classe les articles du bon de commande selon une hiérarchie d’achat. Cette classification sert à analyser les dépenses et à gérer les fournisseurs.

En Process Mining, la segmentation du processus par catégorie d’achat peut révéler des différences de comportement ou de performance. Par exemple, l’approbation des dépenses d’investissement peut prendre plus de temps que celle des fournitures courantes. Cet attribut contribue directement au Dashboard « Taux et motifs de retour des marchandises », qui permet d’analyser les catégories les plus souvent retournées.

Pourquoi est-ce important ?

Permet d’analyser le processus selon le type de dépenses et de repérer les différences de parcours, les goulots d’étranglement ou les taux de retour entre les catégories de marchandises.

Où trouver ces données

Lien entre PO_LINES_ALL.CATEGORY_ID et la vue EGP_CATEGORIES_VL.

Exemples
Informatique.Matériel.Ordinateurs portablesFournitures de bureau.PapeterieServices professionnels.Conseil
Comporte des reprises
IsRework
Indique si le bon de commande a été modifié après sa création initiale.
Description

Cet attribut booléen calculé prend la valeur true si un cas de bon de commande contient l’activité « Purchase Order Changed ». Il permet de repérer rapidement les commandes qui ont 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 ayant fait l’objet de reprises. L’étude de leurs caractéristiques, comme les fournisseurs ou les services concernés, peut aider à déterminer les causes des erreurs de données ou de l’évolution des besoins.

Pourquoi est-ce important ?

Cet attribut contribue directement au KPI « Taux de modification des bons de commande » et facilite l’analyse de l’instabilité du processus en signalant toutes les commandes modifiées.

Où trouver ces données

Champ calculé. Prend la valeur « true » si le journal d’événements d’un cas contient l’activité « Purchase Order Changed », et « false » dans le cas contraire.

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 marchandises ou de services. Cet attribut relie le bon de commande à la demande à l’origine de l’achat.

L’ajout du numéro de demande permet d’analyser le processus d’achat dans son ensemble, depuis la demande initiale et pas seulement à partir du bon de commande. Il peut servir à mesurer le temps de cycle entre la demande et la commande, et à comprendre comment les détails de la demande influent sur les étapes suivantes du processus.

Pourquoi est-ce important ?

Relie le bon de commande à la demande initiale et permet d’analyser le processus de bout en bout, de la demande au paiement.

Où trouver ces données

Lien établi par la table PO_DISTRIBUTIONS_ALL, qui contient REQ_DISTRIBUTION_ID et permet de remonter à 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 de la dernière extraction ou actualisation des données depuis le système source.
Description

Cet attribut indique si les données analysées sont à jour. Il enregistre la date et l’heure de la dernière extraction des données depuis Oracle Fusion Financials.

Cette information aide les utilisateurs à évaluer l’actualité des analyses et des Dashboards. Elle précise la date de mise à jour des analyses de processus et permet de savoir si les transactions les plus récentes sont incluses.

Pourquoi est-ce important ?

Indique clairement l’actualité des données afin que les utilisateurs sachent à quel point l’analyse du processus est récente.

Où trouver ces données

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 ou adresse physique où les marchandises doivent être livrées.
Description

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

Dans le cadre du Process Mining, l’analyse par lieu de livraison contribue au Dashboard « Efficacité du traitement des réceptions de marchandises ». Elle permet de repérer les entrepôts ou les sites où la réception est plus lente et de mettre en évidence d’éventuels problèmes de ressources ou de processus propres à ces lieux.

Pourquoi est-ce important ?

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

Où trouver ces données

Lien entre PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID et la vue HR_LOCATIONS_ALL.

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

Cet attribut booléen calculé prend la valeur true si 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 sert de base au KPI « Taux de livraison à temps ». Il permet de segmenter et d’analyser facilement les commandes livrées en retard ou à temps, afin d’étudier les causes des retards, qu’elles soient liées à certains fournisseurs, sites ou catégories de produits.

Pourquoi est-ce important ?

Cet attribut contribue directement au KPI « Taux de livraison à temps » et permet d’analyser clairement les performances des fournisseurs et la fiabilité des livraisons.

Où trouver ces données

Champ calculé. Prend la valeur « true » si l’horodatage de l’activité « Goods Received » est postérieur à la valeur de l’attribut « RequestedDeliveryDate ».

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 « Ouvert », « Approuvé », « Clôturé définitivement » ou « Annulé ». Il donne un aperçu de l’avancement du bon de commande.

Le Process Mining s’intéresse à la séquence des activités, mais le statut actuel permet de filtrer les cas. L’analyse peut, par exemple, porter uniquement sur les bons de commande ouverts pour examiner les opérations en cours, ou sur les bons clôturés pour étudier les instances terminées. Cet attribut est essentiel au Dashboard « Flux et statut des bons de commande ».

Pourquoi est-ce important ?

Donne un aperçu de l’état actuel d’un bon de commande et permet de filtrer l’analyse selon que les commandes sont en cours, terminées ou annulées.

Où trouver ces données

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

Exemples
OUVERTAPPROUVÉCLÔTURÉ_DÉFINITIVEMENTANNULÉ
Système source
SourceSystem
Système d’information dont les données ont été extraites.
Description

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

Même s’il s’agit souvent d’une valeur fixe pour un jeu de données donné, cet attribut est important pour la gouvernance des données, le dépannage et le suivi de leur provenance. Dans les analyses qui combinent plusieurs sources, il permet de filtrer et de segmenter les données selon leur système d’origine.

Pourquoi est-ce important ?

Indique l’origine des données, un élément important pour leur gouvernance, leur mise en contexte et leur intégration avec d’autres systèmes.

Où trouver ces données

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 », « Cadre » ou « Contrat ».
Description

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

Un bon de commande « Standard » concerne un achat ponctuel, tandis qu’un bon de commande « Cadre » correspond à un accord de plus longue durée avec un fournisseur. L’analyse du processus par type de bon de commande donne une vision plus juste des performances : comparer le temps de cycle d’un bon standard à celui d’un accord-cadre serait trompeur. Elle permet de comparer des commandes similaires.

Pourquoi est-ce important ?

Distingue les différents types d’achats et permet de comparer plus justement les performances du processus entre des commandes de même nature.

Où trouver ces données

Oracle Fusion Cloud SCM, table PO_HEADERS_ALL, colonne TYPE_LOOKUP_CODE.

Exemples
STANDARDCADRECONTRAT
Unité opérationnelle
BusinessUnitName
Unité opérationnelle 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 ses propres rapports financiers. Dans Oracle Fusion, elle constitue un mécanisme essentiel de séparation des données.

Dans les grandes entreprises multinationales, l’analyse des performances du processus par unité opérationnelle permet de comparer l’efficacité des achats, la conformité et les coûts entre les différentes entités de l’organisation. Elle met en évidence les bonnes pratiques et les points à améliorer.

Pourquoi est-ce important ?

Permet aux grandes organisations de comparer l’efficacité et la conformité des processus entre différentes divisions opérationnelles.

Où trouver ces données

L’unité opérationnelle est généralement indiquée dans l’en-tête du bon de commande, dans PO_HEADERS_ALL.PRC_BU_ID, qui renvoie à la vue FUN_ALL_BUSINESS_UNITS_V.

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

Activités du processus Purchase to Pay, bons de commande

Voici les principales étapes et les jalons à enregistrer dans votre journal d’événements pour découvrir avec précision le processus Purchase to Pay, bons de commande.
6 Recommandé 10 Facultatif
Activité Description
Bon de commande annulé
Le bon de commande a été définitivement annulé et aucune autre transaction n’est attendue. Cette action explicite modifie le statut final du document.
Pourquoi est-ce important ?

Cette activité correspond à 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 de budget ou une évolution des besoins du projet.

Où trouver ces données

Cette action est enregistrée dans la table PO_ACTION_HISTORY avec la valeur 'CANCEL' dans le champ ACTION_CODE. Le statut du bon de commande est alors mis à jour dans PO_HEADERS_ALL.

Données à recueillir

Filtrez PO_ACTION_HISTORY sur ACTION_CODE = 'CANCEL'.

Type d’événement explicit
Bon de commande définitivement clôturé
Le bon de commande est considéré comme terminé : les marchandises ont été entièrement réceptionnées et/ou les factures ont été traitées, et aucune autre activité n’est prévue. Cette action explicite attribue un statut final au bon de commande.
Pourquoi est-ce important ?

Cette activité marque la fin du cycle de vie du bon de commande. Elle constitue la principale issue positive du processus. Son suivi est essentiel pour mesurer le débit global du processus et le taux d’achèvement.

Où trouver ces données

Cet événement est enregistré dans la table PO_ACTION_HISTORY avec la valeur 'FINALLY CLOSE' dans le champ ACTION_CODE. Le statut du bon de commande est également mis à jour dans PO_HEADERS_ALL et prend la valeur 'Finally Closed'.

Données à recueillir

Filtrez PO_ACTION_HISTORY sur ACTION_CODE = 'FINALLY CLOSE'.

Type d’événement explicit
Commande d’achat approuvée
La commande d’achat a reçu toutes les approbations nécessaires et peut maintenant être envoyée au fournisseur. Cette étape clé est explicitement consignée dans l’historique des actions du document.
Pourquoi est-ce important ?

Cette étape clé conditionne l’envoi de la commande d’achat au fournisseur. Elle est essentielle pour mesurer les temps de cycle d’approbation et vérifier le respect des politiques de dépenses.

Où trouver ces données

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 à l’état approuvé.

Données à recueillir

Filtrez PO_ACTION_HISTORY sur l’action finale 'APPROVE'.

Type d’événement explicit
Commande d’achat créée
Cette étape marque le début officiel du cycle de vie de la commande d’achat. Le document de commande est créé avec le statut Brouillon ou incomplet. Le système enregistre cet événement à l’aide de l’horodatage de création de l’en-tête de la nouvelle commande.
Pourquoi est-ce important ?

En tant qu’événement de début du cas de commande d’achat, cette activité est essentielle au calcul des temps de cycle. Elle sert de référence pour mesurer l’efficacité des étapes suivantes, comme l’approbation et la communication avec le fournisseur.

Où trouver ces données

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

Données à recueillir

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

Type d’événement explicit
Commande d’achat envoyée au fournisseur
La commande d’achat approuvée est officiellement communiquée au fournisseur, par exemple par e-mail ou par EDI. Cet événement est souvent déduit d’un changement de statut ou d’un horodatage dans l’enregistrement de communication de la commande.
Pourquoi est-ce important ?

Cette étape marque le début du délai d’approvisionnement du fournisseur. Elle sert de point de départ pour mesurer ses performances, de l’accusé de réception à la livraison finale.

Où trouver ces données

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

Données à recueillir

Déduisez l’événement de l’horodatage auquel le statut de communication de la commande passe à « Communicated ».

Type d’événement inferred
Marchandises reçues
Les marchandises ont été réceptionnées physiquement, comptées et enregistrées pour le bon de commande. Cet événement transactionnel met à jour le stock et le statut du bon de commande.
Pourquoi est-ce important ?

Cette étape constitue un jalon important pour mesurer la performance des livraisons des fournisseurs dans les délais et le délai global. Elle déclenche également les activités suivantes, comme le contrôle qualité et le rapprochement des factures.

Où trouver ces données

Cet événement explicite est enregistré dans la table RCV_TRANSACTIONS. La transaction correspondante est identifiable grâce à la valeur 'RECEIVE' du champ TRANSACTION_TYPE.

Données à recueillir

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

Type d’événement explicit
Commande d’achat confirmée
Le fournisseur a confirmé la réception de la commande d’achat et accepté ses conditions. Cet événement est souvent saisi manuellement par le personnel des achats à partir des échanges avec le fournisseur, ou enregistré au moyen d’un accusé de réception électronique.
Pourquoi est-ce important ?

La confirmation du fournisseur garantit 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 de repérer rapidement les problèmes éventuels d’exécution.

Où trouver ces données

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

Données à recueillir

Déduisez l’événement des mises à jour des champs de statut de confirmation de la commande.

Type d’événement inferred
Commande d’achat modifiée
Une modification a été apportée au bon de commande après son approbation initiale, par exemple un changement de quantité, de prix ou de date de livraison. Oracle Fusion enregistre cette modification en créant une nouvelle version du document.
Pourquoi est-ce important ?

Les modifications apportées aux bons de commande entraînent des reprises et peuvent révéler des problèmes dans la précision des commandes initiales ou une évolution des besoins de l’entreprise. L’analyse de leur fréquence et de leur nature permet de repérer des pistes pour améliorer l’efficacité du processus.

Où trouver ces données

Cet événement est explicitement enregistré lors de la création d’une nouvelle version du document. Il est possible de le repérer grâce à l’incrémentation du champ REVISION_NUM dans la table PO_HEADERS_ALL.

Données à recueillir

Repérez chaque cas où la valeur de REVISION_NUM augmente pour un PO_HEADER_ID.

Type d’événement explicit
Commande d’achat rejetée
Un approbateur a rejeté la commande d’achat et l’a renvoyée à son créateur pour révision. Cet événement explicite est consigné dans l’historique des actions et signale une rupture du flux de processus habituel.
Pourquoi est-ce important ?

Les rejets entraînent des reprises et des retards. Le suivi de cette activité aide à repérer les motifs de rejet récurrents, les besoins de formation ou les exigences d’approbation qui manquent de clarté.

Où trouver ces données

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

Données à recueillir

Filtrez PO_ACTION_HISTORY sur ACTION_CODE = 'REJECT'.

Type d’événement explicit
Commande d’achat soumise
La commande d’achat créée est soumise au flux de travail d’approbation. Oracle Fusion consigne explicitement cette action, avec l’utilisateur et l’horodatage de la soumission.
Pourquoi est-ce 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 dans le processus de validation interne.

Où trouver ces données

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

Données à recueillir

Filtrez PO_ACTION_HISTORY sur 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é a lieu après la réception initiale et fait l’objet d’une transaction distincte.
Pourquoi est-ce important ?

Cette activité est importante pour la gestion de la qualité. L’analyse de la durée des inspections permet d’optimiser le contrôle qualité et de réduire les délais avant que les marchandises puissent être utilisées.

Où trouver ces données

Cette activité est enregistrée dans la table RCV_TRANSACTIONS. Elle correspond aux transactions dont le champ TRANSACTION_TYPE vaut 'ACCEPT' ou 'REJECT' et qui suivent une transaction de réception.

Données à recueillir

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, qui autorise ainsi le service des achats à créer une commande d’achat. Cet événement est explicitement consigné dans l’historique des actions de la demande.
Pourquoi est-ce important ?

Cette étape marque la fin du processus d’approbation interne de la demande. Tout retard à ce stade peut avoir un effet direct sur l’ensemble du calendrier d’approvisionnement. Il est donc important d’en suivre la durée.

Où trouver ces données

Cet événement est consigné dans l’historique des actions associé à la demande, généralement dans les tables de flux de travail ou dans des champs de statut d’approbation du document.

Données à recueillir

L’événement est 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 une commande d’achat. 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 est-ce important ?

L’analyse de cette activité permet de comprendre l’origine de la demande. Le suivi du délai entre la demande d’achat et la création de la commande révèle les retards éventuels dans la conversion des besoins internes en commandes d’approvisionnement.

Où trouver ces données

Il s’agit d’un événement explicite enregistré lors de l’enregistrement d’une nouvelle demande. Il peut être repéré à partir de l’horodatage de création dans la table POR_REQUISITION_HEADERS_ALL.

Données à recueillir

L’événement est basé 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. Le module de réception enregistre cette opération sous la forme d’une transaction de retour spécifique.
Pourquoi est-ce important ?

Le suivi des retours est essentiel pour évaluer la qualité des fournisseurs et la précision des commandes. Un taux de retour élevé pour un fournisseur peut révéler des problèmes récurrents à résoudre.

Où trouver ces données

Cet événement explicite est enregistré dans la table RCV_TRANSACTIONS avec la valeur 'RETURN TO VENDOR' dans le champ TRANSACTION_TYPE.

Données à recueillir

Utilisez la valeur de 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 prestations ont été réalisées conformément à ce qui était convenu. La confirmation est souvent saisie manuellement ou au moyen d’une feuille de saisie des services.
Pourquoi est-ce important ?

Cette étape équivaut à la réception de marchandises pour les services et doit être effectuée avant le paiement d’une facture. Un retard dans la confirmation des prestations peut entraîner des paiements tardifs et détériorer les relations avec les fournisseurs.

Où trouver ces données

Cette activité est généralement enregistrée comme une réception associée à une ligne de service du bon de commande. Elle peut s’appuyer sur des champs spécifiques ou sur des réceptions complexes permettant de suivre l’avancement ou l’achèvement des prestations.

Données à recueillir

Repérez 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 des marchandises créée
Un document de réception est créé dans le système en prévision de l’arrivée physique des marchandises. Cette activité marque le début du processus de réception interne.
Pourquoi est-ce important ?

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

Où trouver ces données

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

Données à recueillir

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 extraire vos données d’Oracle Fusion Financials

Prêt à commencer ?

Utilisez ce modèle pour simplifier la collecte de vos données et commencer à analyser votre processus Purchase to Pay, bons de commande. Commencez dès aujourd’hui à optimiser vos opérations.

Optimisez dès aujourd’hui votre processus Purchase to Pay, bons de commande

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

Démarrez l’essai gratuit

Aucune carte bancaire n’est requise. Commencez dès aujourd’hui à optimiser vos opérations.