Votre modèle de données Purchase to Pay, bons de commande
Votre modèle de données Purchase to Pay, bons de commande
- 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
Attributs du processus Purchase to Pay, bons de commande
| 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
|
|||
Activités du processus Purchase to Pay, bons de commande
| 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
|
|||
Guides d’extraction
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 %.
Aucune carte bancaire n’est requise. Commencez dès aujourd’hui à optimiser vos opérations.