Votre modèle de données Purchase to Pay - Purchase Order
Votre modèle de données Purchase to Pay - Purchase Order
- 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
Purchase to Pay - Purchase Order : attributs
| 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
|
|||
Purchase to Pay - Purchase Order : activités
| 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
|
|||
Guides d’extraction
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 %.
Aucune carte bancaire requise, commencez à optimiser dès aujourd’hui.