Data Template : Achats au paiement - Commande d'achat
Votre Modèle de données de commande d'achat pour le processus Achats au Paiement
- Attributs recommandés pour une collecte de données exhaustive
- Activités clés du processus à suivre et analyser
- Guide d'extraction étape par étape pour Oracle Fusion Financials
Achat au Paiement - Attributs de Commande d'achat
| Nom | Description | ||
|---|---|---|---|
|
Activité
ActivityName
|
Le nom d'un événement métier ou d'une étape spécifique survenue au cours du cycle de vie du Bon de Commande. | ||
|
Description
Cet attribut décrit une tâche spécifique ou un changement de statut dans le processus, comme 'Commande d'achat créée' ou 'Marchandises reçues'. Ces activités forment la séquence d'événements qui constituent le flux de processus. L'analyse de la séquence et de la chronologie de ces activités est au cœur du Process Mining. Elle permet de visualiser la cartographie des processus, d'identifier les goulots d'étranglement, de détecter les écarts par rapport à la procédure standard et de mesurer la durée des étapes spécifiques.
Pourquoi c'est important
Les activités sont les éléments constitutifs de la carte des processus. Leur suivi permet la visualisation et l'analyse du flux de processus, des goulots d'étranglement et des écarts.
Où obtenir
Dérivé des changements de statut dans des tables comme PO_HEADERS_ALL et PO_ACTION_HISTORY, ou de tables de transaction 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
|
L'identifiant unique du document de Bon de Commande, servant d'ID de cas principal pour le suivi du cycle de vie des approvisionnements. | ||
|
Description
Le numéro de Bon de Commande est l'identifiant central qui relie toutes les activités connexes, de sa création à sa clôture finale. Il permet une analyse de bout en bout d'un cas d'approvisionnement unique. En Process Mining, chaque numéro de Bon de Commande unique représente une instance du processus. L'analyse des données regroupées par cet identifiant aide à comprendre les variations de processus, les temps de cycle et la conformité pour les commandes individuelles.
Pourquoi c'est important
Il s'agit de l'ID de cas essentiel qui relie tous les événements associés, permettant la reconstruction et l'analyse du cycle de vie complet du Bon de Commande.
Où obtenir
Oracle Fusion Cloud SCM, Module Achats, table PO_HEADERS_ALL, colonne SEGMENT1.
Exemples
100234510023461002347
|
|||
|
Heure de début
EventTime
|
L'horodatage indiquant quand une activité ou un événement spécifique s'est produit. | ||
|
Description
Cet attribut enregistre la date et l'heure exactes pour chaque activité dans le processus. Il est fondamental pour l'ordonnancement chronologique des événements et pour toutes les analyses basées sur le temps. En Process Mining, l'heure de début est utilisée pour construire le journal d'événements, calculer les temps de cycle entre les activités, mesurer les temps d'attente et analyser la performance du processus sur différentes périodes. Il est essentiel pour les dashboards liés au temps de cycle et à la performance.
Pourquoi c'est important
Cet horodatage est essentiel pour le séquençage correct des événements et le calcul de toutes les métriques basées sur la durée, telles que les temps de cycle et les goulots d'étranglement.
Où obtenir
Champs d'horodatage tels que CREATION_DATE et LAST_UPDATE_DATE provenant de diverses tables, y compris 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
|
La date à laquelle la partie requérante s'attend à ce que les biens ou services soient livrés. | ||
|
Description
Cette date est spécifiée sur la ligne de commande d'achat et communique le délai de livraison souhaité au fournisseur. Elle sert de référence pour mesurer la performance de livraison à temps. Cet attribut est critique pour le calcul du KPI 'Taux de livraison à temps'. En comparant la date de réception réelle des marchandises avec la date de livraison demandée, les organisations peuvent mesurer et suivre quantitativement la fiabilité des fournisseurs et identifier les retards systémiques dans la chaîne d'approvisionnement.
Pourquoi c'est important
Sert de référence pour mesurer la performance de livraison dans les délais, un indicateur clé de performance (KPI) pour évaluer la fiabilité des fournisseurs et l'efficacité de la chaîne d'approvisionnement.
Où obtenir
Situé au niveau de la localisation de la ligne, dans la table PO_LINE_LOCATIONS_ALL, colonne NEED_BY_DATE.
Exemples
2023-05-202023-06-152023-07-01
|
|||
|
Département
DepartmentName
|
Le nom du service qui a initié ou est responsable du Bon de Commande. | ||
|
Description
Cet attribut spécifie l'unité organisationnelle, telle que 'Finance', 'IT' ou 'Production', associée à l'achat. Il est utilisé pour l'affectation des coûts et le reporting organisationnel. Dans un contexte de Process Mining, segmenter le processus par département est crucial pour comparer la performance, identifier les goulots d'étranglement spécifiques à un département et comprendre les variations dans l'exécution du processus au sein de l'organisation. Il alimente directement des dashboards comme 'Analyse du temps de cycle d'approbation des PO' et 'Tendances de modification des commandes d'achat'.
Pourquoi c'est important
Permet de filtrer et de comparer la performance des processus au sein des différentes unités commerciales, révélant des problèmes spécifiques à chaque département ou les meilleures pratiques.
Où obtenir
Dérivé des informations de centre de coûts dans des tables comme PO_DISTRIBUTIONS_ALL, qui sont liées aux données de base des services.
Exemples
Opérations ITMarketingRecherche et Développement
|
|||
|
Heure de fin
EndTime
|
L'horodatage de l'achèvement d'une activité. Souvent le même que l'Heure de début pour les événements atomiques. | ||
|
Description
Pour les activités ayant une durée, cela marque l'heure de fin. Pour les événements instantanés, c'est généralement la même que l'heure de début. C'est essentiel pour calculer le temps de traitement des activités individuelles. Avoir une heure de fin distincte permet une analyse plus précise des durées d'activité, qui peuvent être différentes du temps d'attente entre les activités. Cela aide à différencier le temps de travail actif du temps d'inactivité, soutenant l'analyse de la charge de travail des ressources et de l'efficacité.
Pourquoi c'est important
Permet le calcul des temps de traitement précis des activités, ce qui est essentiel pour analyser l'efficacité des ressources et identifier les tâches chronophages.
Où obtenir
Peut être identique à l'Heure de début pour les événements atomiques ou dérivé des timestamps d'événements subséquents. Pour certaines activités, un timestamp de fin distinct peut exister.
Exemples
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
Montant total du bon de commande
PurchaseOrderTotalAmount
|
La valeur monétaire totale du Bon de Commande. | ||
|
Description
Cet attribut représente le coût total de tous les articles sur la Commande d'achat dans la devise spécifiée. C'est une métrique financière clé pour comprendre la valeur des transactions circulant dans le processus. L'analyse du Montant total du bon de commande aide à prioriser les efforts d'amélioration des processus. Par exemple, les commandes de grande valeur pourraient être acheminées via un processus d'approbation plus rigoureux. Elle permet également l'analyse d'impact financier, comme le calcul de la valeur des bons de commande qui sont fréquemment modifiés ou retardés.
Pourquoi c'est important
Apporte un contexte financier au processus, permettant une analyse basée sur la valeur monétaire, par exemple en se concentrant sur les commandes de grande valeur ou en comprenant les impacts financiers des retards.
Où obtenir
Calculé en additionnant les montants de PO_LINES_ALL pour un en-tête de commande d'achat donné, ou extrait d'un total au niveau de l'en-tête si disponible.
Exemples
5250.00120000.50750.99
|
|||
|
Nom de l'approbateur
ApproverName
|
Le nom de l'utilisateur qui a 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 workflow. Cette information est généralement stockée dans une table d'historique des actions ou de journal d'événements du workflow associée au Bon de Commande. L'analyse des données par approbateur est cruciale pour les dashboards « Analyse du temps de cycle d'approbation des Bons de Commande » et « Charge de travail des ressources d'approbation ». Elle aide à identifier les approbateurs ou groupes d'approbation qui constituent des goulots d'étranglement, permet une évaluation équitable de la charge de travail et peut mettre en évidence des opportunités de délégation ou de refonte des processus.
Pourquoi c'est important
Identifie les individus dans la chaîne d'approbation, permettant d'analyser les goulots d'étranglement d'approbation, la charge de travail et les temps de cycle par approbateur.
Où obtenir
L'utilisateur qui a effectué l'action, dont l'identifiant se trouve dans PO_ACTION_HISTORY.ACTION_PERFORMED_BY, et qui est lié à une table d'utilisateurs pour obtenir le nom complet.
Exemples
susan.managerdavid.directoremily.finance
|
|||
|
Nom du fournisseur
VendorName
|
Le nom du fournisseur auprès duquel les biens ou services sont achetés. | ||
|
Description
Cet attribut identifie le fournisseur externe pour la Commande d'achat. C'est une donnée maîtresse critique liée à l'en-tête du bon de commande. L'analyse des fournisseurs est un élément clé du Process Mining du processus Achats-Paiements. En filtrant ou en segmentant par fournisseur, les entreprises peuvent analyser la performance de livraison des fournisseurs, comparer les taux de livraison à temps et examiner le taux de retour de marchandises pour identifier les fournisseurs performants ou peu performants. Ces données sont essentielles pour la gestion des relations fournisseurs et l'approvisionnement stratégique.
Pourquoi c'est important
Essentiel pour l'analyse de la performance des fournisseurs, permettant la comparaison des délais de livraison, des taux de retour et de la fiabilité globale entre les fournisseurs.
Où obtenir
Lié de PO_HEADERS_ALL.VENDOR_ID à POZ_SUPPLIERS.VENDOR_NAME.
Exemples
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
|
|||
|
Utilisateur
UserName
|
L'identifiant ou le nom de l'utilisateur qui a effectué l'activité. | ||
|
Description
Cet attribut identifie l'employé ou l'utilisateur du système responsable d'un événement donné, comme la création d'une demande, l'approbation d'un bon de commande (PO) ou la saisie d'une réception de marchandises. Il est généralement extrait 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, la performance individuelle et à identifier les besoins en formation. Elle est essentielle pour le dashboard 'Charge de travail des ressources d'approbation' et pour enquêter sur les problèmes de conformité liés aux actions des utilisateurs.
Pourquoi c'est important
Attribue les actions des utilisateurs à des personnes spécifiques, permettant d'analyser la charge de travail, d'évaluer les performances et d'identifier les opportunités de formation.
Où obtenir
Joindre aux tables utilisateur sur la base des identifiants dans des champs tels que CREATED_BY ou LAST_UPDATED_BY au sein de tables comme PO_HEADERS_ALL et PO_ACTION_HISTORY.
Exemples
john.doejane.smithsystem.batch
|
|||
|
Catégorie d'achat
PurchaseCategory
|
La classification des biens ou services achetés, comme « Matériel Informatique » ou « Fournitures de Bureau ». | ||
|
Description
Cet attribut catégorise 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. En Process Mining, segmenter le 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 pour les dépenses d'investissement peut être plus long que pour les fournitures opérationnelles. Cela soutient directement le dashboard « Taux de retour des marchandises et raisons » en permettant d'analyser les catégories les plus fréquemment retournées.
Pourquoi c'est important
Permet l'analyse des processus par type de dépense, ce qui peut révéler différents chemins de processus, goulots d'étranglement, ou taux de retour pour différentes catégories de marchandises.
Où obtenir
Lié de PO_LINES_ALL.CATEGORY_ID à la vue EGP_CATEGORIES_VL.
Exemples
IT.Hardware.LaptopsOffice.Supplies.StationeryProfessional.Services.Consulting
|
|||
|
Demande d'achat
PurchaseRequisitionNumber
|
L'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 solliciter l'achat de biens ou services. Cet attribut relie le Bon de Commande à sa demande d'origine. L'inclusion du numéro de demande permet une analyse plus large du processus d'approvisionnement, en partant de la demande initiale plutôt que du seul Bon de Commande. Cela peut aider à analyser le temps de cycle entre la demande et la commande, et à comprendre comment les détails de la demande influencent le processus en aval du Bon de Commande.
Pourquoi c'est important
Relie le bon de commande à la demande initiale, permettant une vue de processus de bout en bout plus complète, de la réquisition au paiement.
Où obtenir
Lié via la table PO_DISTRIBUTIONS_ALL, qui contient REQ_DISTRIBUTION_ID, remontant à 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
|
L'horodatage de la dernière extraction ou actualisation des données depuis le système source. | ||
|
Description
Cet attribut indique l'actualité des données analysées. Il enregistre la date et l'heure de la dernière extraction de données d'Oracle Fusion Financials. Cette information est vitale pour que les utilisateurs comprennent la pertinence temporelle de l'analyse et des dashboards. Elle clarifie le niveau de mise à jour des informations sur les processus, permettant ainsi de gérer les attentes concernant l'inclusion de transactions très récentes.
Pourquoi c'est important
Offre une transparence sur l'actualité des données, garantissant que les utilisateurs comprennent à quel point l'analyse du processus est à jour.
Où obtenir
Il s'agit d'un horodatage généré et ajouté pendant le processus d'extraction, de transformation et de chargement (ETL) des données.
Exemples
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Durée du cycle d'approbation
ApprovalCycleTime
|
La durée entre la création d'un Bon de Commande et son approbation finale. | ||
|
Description
Il s'agit d'une métrique de durée calculée qui mesure le temps écoulé entre l'activité 'Purchase Order Created' et l'activité 'Purchase Order Approved' pour un cas unique. Cet attribut fournit directement la valeur du KPI 'Average PO Approval Cycle Time'. L'analyse de sa distribution aide à comprendre l'efficacité du flux de travail d'approbation, à identifier les valeurs aberrantes et à mesurer l'impact des initiatives d'amélioration des processus visant à réduire les retards d'approbation.
Pourquoi c'est important
Quantifie le goulot d'étranglement d'approbation, mesurant directement l'indicateur clé de performance (KPI) 'Temps de cycle moyen d'approbation de la commande d'achat' et mettant en évidence les retards dans le workflow.
Où obtenir
Champ calculé. La différence entre les timestamps des activités 'Commande d'achat approuvée' et 'Commande d'achat créée'.
Exemples
P2DPT8H30MP5DT12H
|
|||
|
Est un retravail
IsRework
|
Un indicateur signalant si le bon de commande a été modifié après sa création initiale. | ||
|
Description
Il s'agit d'un attribut booléen calculé qui prend la valeur vrai si un cas 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 'PO Modification Rate' et facilite le filtrage et l'analyse des commandes retravaillées. Comprendre les caractéristiques des commandes retravaillées, telles que les fournisseurs ou les départements impliqués, peut aider à identifier les causes profondes d'inexactitudes des données ou d'exigences changeantes.
Pourquoi c'est important
Prend directement en charge le KPI « Taux de modification des commandes d'achat » et simplifie l'analyse de l'instabilité des processus en signalant toutes les commandes ayant subi des modifications.
Où obtenir
Champ calculé. Défini sur 'vrai' si le journal d'événements pour un cas contient l'activité 'Commande d'achat modifiée', sinon 'faux'.
Exemples
truefaux
|
|||
|
L'approbation est-elle conforme
IsApprovalCompliant
|
Un indicateur signalant si le bon de commande a été approuvé avant d'être envoyé au fournisseur. | ||
|
Description
Il s'agit d'un attribut booléen calculé qui vérifie le respect d'un contrôle interne clé : un Bon de Commande doit être approuvé avant d'être envoyé à un fournisseur. Sa valeur est vraie si l'activité 'Purchase Order Approved' se produit avant l'activité 'Purchase Order Sent to Vendor'. Cet attribut est essentiel pour le tableau de bord 'PO Process Compliance Audit' et le KPI 'PO Approval Compliance Rate'. Il offre un moyen simple d'identifier et de quantifier les violations de conformité, contribuant à faire respecter les politiques d'approvisionnement et à atténuer les risques liés aux dépenses non autorisées.
Pourquoi c'est important
Mesure directement le KPI « Taux de conformité des approbations de commandes d'achat », mettant en évidence les violations critiques des contrôles internes lorsque les commandes sont envoyées aux fournisseurs avant approbation.
Où obtenir
Champ calculé. Défini sur 'vrai' si le timestamp de 'Commande d'achat approuvée' est inférieur ou égal au timestamp de 'Commande d'achat envoyée au fournisseur'.
Exemples
truefaux
|
|||
|
Lieu de livraison
DeliveryLocation
|
L'emplacement physique ou l'adresse de livraison des biens. | ||
|
Description
Cet attribut spécifie l'adresse de livraison pour les articles de la Commande d'achat. C'est une information logistique clé. Pour le Process Mining, l'analyse par lieu de livraison alimente le dashboard 'Efficacité du traitement des réceptions de marchandises'. Elle aide à identifier si certains entrepôts ou sites sont plus lents dans leur processus de réception, signalant de potentiels problèmes de ressources ou de processus à des endroits spécifiques.
Pourquoi c'est important
Permet d'analyser les performances par emplacement géographique, aidant à identifier les goulots d'étranglement régionaux ou spécifiques aux sites dans le processus de réception des marchandises.
Où obtenir
Lié de PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID à la vue HR_LOCATIONS_ALL.
Exemples
Entrepôt principal - Quai ABâtiment 3 - RéceptionBureau de SF - 10e étage
|
|||
|
Statut du bon de commande
PurchaseOrderStatus
|
Le statut actuel du document de Bon de Commande. | ||
|
Description
Cet attribut indique l'état actuel de la Commande d'achat dans son cycle de vie, tel que 'Ouverte', 'Approuvée', 'Clôturée définitivement' ou 'Annulée'. Il fournit un aperçu de l'avancement du bon de commande. Alors que le Process Mining se concentre sur la séquence des activités, le statut actuel est précieux pour le filtrage des cas. Par exemple, l'analyse peut être centrée uniquement sur les bons de commande ouverts pour comprendre le pipeline actuel, ou sur les bons de commande clôturés pour analyser les instances de processus complétées. Il est essentiel pour le dashboard 'Flux et statut des commandes d'achat'.
Pourquoi c'est important
Fournit un instantané de l'état actuel d'une commande d'achat, ce qui permet de filtrer l'analyse sur les commandes actives, terminées ou annulées.
Où obtenir
Oracle Fusion Cloud SCM, table PO_HEADERS_ALL, colonnes AUTHORIZATION_STATUS ou DOCUMENT_STATUS.
Exemples
OPENAPPROUVÉFINALLY_CLOSEDANNULÉ
|
|||
|
Système source
SourceSystem
|
Le 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 avec plusieurs systèmes intégrés. Pour ce processus, il s'agirait généralement de 'Oracle Fusion Financials'. Bien que souvent une valeur statique pour un jeu de données donné, elle est cruciale pour la gouvernance des données, le dépannage et la traçabilité des données. Dans les analyses qui combinent des données de plusieurs sources, elle permet le filtrage et la segmentation par système d'origine.
Pourquoi c'est important
Identifie l'origine des données, ce qui est crucial pour la gouvernance des données, le contexte et l'intégration avec d'autres systèmes.
Où obtenir
Il s'agit généralement d'une valeur constante définie et ajoutée pendant le processus d'extraction, de transformation et de chargement (ETL) des données.
Exemples
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
|
|||
|
Type de bon de commande
PurchaseOrderType
|
Le type de Bon de Commande, tel que « Standard », « Cadre » ou « Contrat ». | ||
|
Description
Cet attribut classifie le Bon de Commande en fonction de son objectif d'approvisionnement. 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 » est un achat unique, tandis qu'un Bon de Commande « Cadre » est un accord à plus long terme avec un fournisseur. L'analyse du processus par type de Bon de Commande permet une vision plus précise de la performance du processus, car comparer le temps de cycle d'un Bon de Commande standard à un accord cadre serait trompeur. Cela facilite des comparaisons équitables.
Pourquoi c'est important
Différencie les différents scénarios d'approvisionnement, permettant des comparaisons plus précises et pertinentes de la performance des processus pour des types de commandes similaires.
Où obtenir
Oracle Fusion Cloud SCM, table PO_HEADERS_ALL, colonne TYPE_LOOKUP_CODE.
Exemples
STANDARDCOMMANDE-CADRECONTRAT
|
|||
|
Unité commerciale
BusinessUnitName
|
La Business Unit spécifique au sein de l'organisation qui effectue l'achat. | ||
|
Description
La Business Unit représente une entité métier distincte au sein de l'entreprise, souvent dotée de son propre grand livre et de sa propre comptabilité. C'est un mécanisme principal de ségrégation des données dans Oracle Fusion. L'analyse des performances de processus par Business Unit est cruciale pour les grandes entreprises multinationales. Elle permet de comparer l'efficacité des approvisionnements, la conformité et les coûts entre les différentes entités de l'organisation, mettant en lumière les meilleures pratiques et les pistes d'amélioration.
Pourquoi c'est important
Crucial pour les grandes organisations de comparer l'efficacité des processus et la conformité entre les différentes divisions opérationnelles.
Où obtenir
Le contexte de l'unité commerciale se trouve généralement dans l'en-tête de la commande d'achat, PO_HEADERS_ALL.PRC_BU_ID, qui renvoie à la vue FUN_ALL_BUSINESS_UNITS_V.
Exemples
Unité Commerciale AméricaineEMEA VisionAPAC Services
|
|||
|
Y a-t-il un retard de livraison
IsLateDelivery
|
Un indicateur signalant si la réception finale des marchandises est survenue après la date de livraison souhaitée. | ||
|
Description
Cet attribut booléen calculé est vrai si le timestamp de l'activité 'Marchandises reçues' est postérieur à la valeur de l'attribut 'Date de livraison demandée' pour une Commande d'achat donnée. Cet indicateur est la base du KPI 'Taux de livraison à temps'. Il permet une segmentation et une analyse faciles des commandes en retard par rapport aux commandes à temps, aidant à investiguer les causes profondes des retards, qu'ils soient liés à des fournisseurs spécifiques, des lieux ou des catégories de produits.
Pourquoi c'est important
Prend directement en charge le KPI « Taux de livraison à temps », permettant une analyse claire de la performance des fournisseurs et de la fiabilité des livraisons.
Où obtenir
Champ calculé. Défini sur 'vrai' si le timestamp de l'activité 'Marchandises reçues' est postérieur à l'attribut 'Date de livraison demandée'.
Exemples
truefaux
|
|||
Achat au Paiement - Activités de Commande d'achat
| Activité | Description | ||
|---|---|---|---|
|
Commande d'achat annulée
|
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 un état final négatif pour le processus. L'analyse des annulations peut révéler des problèmes tels que des commandes en double, des modifications budgétaires ou des changements dans les exigences du projet.
Où obtenir
Cette action est enregistrée dans la table PO_ACTION_HISTORY avec un ACTION_CODE de « CANCEL », et le statut du Bon de Commande dans PO_HEADERS_ALL est mis à jour en conséquence.
Capture
Filtrez PO_ACTION_HISTORY pour ACTION_CODE = 'CANCEL'.
Type d'événement
explicit
|
|||
|
Commande d'achat approuvée
|
Le bon de commande a reçu toutes les approbations nécessaires et est maintenant autorisé à être envoyé au fournisseur. Il s'agit d'un jalon clé, explicitement enregistré dans l'historique des actions du document. | ||
|
Pourquoi c'est important
C'est un jalon critique qui conditionne l'envoi du PO au fournisseur. Il est essentiel pour mesurer les temps de cycle d'approbation et garantir la conformité aux politiques de dépenses.
Où obtenir
Cet événement est enregistré dans la table PO_ACTION_HISTORY, généralement avec un ACTION_CODE de 'APPROVE' ou lorsque le statut du document dans PO_HEADERS_ALL passe à un état approuvé.
Capture
Filtrez PO_ACTION_HISTORY pour l'action finale 'APPROVE'.
Type d'événement
explicit
|
|||
|
Commande d'achat créée
|
Cet événement marque le début officiel du cycle de vie du bon de commande, lorsqu'un document de PO est généré à l'état d'ébauche ou incomplet. Le système capture cet événement en enregistrant l'horodatage de création du nouvel enregistrement d'en-tête de PO. | ||
|
Pourquoi c'est important
En tant qu'event de départ principal pour le cas de la commande d'achat, cette activité est fondamentale pour tous les calculs de temps de cycle. Elle fournit la base de référence pour mesurer l'efficacité des étapes ultérieures comme l'approbation et la communication avec le fournisseur.
Où obtenir
Il s'agit d'un événement explicite basé sur le champ CREATION_DATE dans la table PO_HEADERS_ALL pour un ID de Bon de Commande donné (PO_HEADER_ID).
Capture
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 EDI. Cet événement est souvent déduit d'un changement de statut ou d'un timestamp sur l'enregistrement de communication de la commande d'achat. | ||
|
Pourquoi c'est important
Cet événement marque le début du délai de livraison du fournisseur. C'est un point crucial pour mesurer la performance du fournisseur, de l'accusé de réception à la livraison finale.
Où obtenir
Ceci peut être inféré du changement de statut du document PO en 'Ouvert' et du renseignement d'une date de communication. Le champ spécifique est souvent PO_HEADERS_ALL.communicated_date ou un statut connexe.
Capture
Déduire de l'horodatage le moment où le statut de communication du bon de commande passe à 'Communiqué'.
Type d'événement
inferred
|
|||
|
Commande d'achat finalement clôturée
|
Le bon de commande est considéré comme complet, ce qui signifie qu'il a été entièrement réceptionné et/ou facturé, et qu'aucune autre activité n'est anticipée. Il s'agit d'une action explicite qui définit un statut final pour le 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'état final positif principal, et son suivi est essentiel pour mesurer le débit global du processus et les taux d'achèvement.
Où obtenir
Cet événement est enregistré dans la table PO_ACTION_HISTORY avec un ACTION_CODE de 'FINALLY CLOSE'. Le statut du bon de commande dans PO_HEADERS_ALL est également mis à jour à 'Clôturé définitivement'.
Capture
Filtrez PO_ACTION_HISTORY pour ACTION_CODE = 'FINALLY CLOSE'.
Type d'événement
explicit
|
|||
|
Marchandises reçues
|
Les biens physiques ont été réceptionnés, comptés et enregistrés en lien avec le bon de commande. Il s'agit d'un événement transactionnel qui met à jour l'inventaire et le statut du Bon de Commande. | ||
|
Pourquoi c'est important
C'est un jalon clé pour mesurer la ponctualité des livraisons des fournisseurs et le délai global. Il sert également de déclencheur pour les activités ultérieures telles que l'inspection qualité et le rapprochement des factures.
Où obtenir
Il s'agit d'un événement explicite enregistré dans la table RCV_TRANSACTIONS. La transaction spécifique peut être identifiée par un TRANSACTION_TYPE de 'RÉCEPTION'.
Capture
Utilisez le TRANSACTION_DATE de RCV_TRANSACTIONS lorsque le TRANSACTION_TYPE est 'RÉCEPTION'.
Type d'événement
explicit
|
|||
|
Commande d'achat confirmée
|
Le fournisseur a confirmé la réception et l'acceptation des conditions du bon de commande. Cet événement est souvent enregistré manuellement par le personnel des approvisionnements suite à une communication du fournisseur ou via un accusé de réception électronique. | ||
|
Pourquoi c'est important
La confirmation du fournisseur garantit que la commande a été reçue et est en cours de traitement. Le suivi de cette étape aide à gérer la communication avec les fournisseurs et à identifier de manière proactive les problèmes potentiels de réalisation.
Où obtenir
Cet événement est généralement inféré d'un changement dans les champs de statut d'accusé de réception sur l'en-tête ou les lignes du PO, tel que PO_HEADERS_ALL.acceptance_status passant à 'Accepté'.
Capture
Déduire des mises à jour des champs de statut d'accusé de réception du bon de 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, comme un changement de quantité, de prix ou de date de livraison. Oracle Fusion assure le suivi de cette modification en créant une nouvelle révision du document. | ||
|
Pourquoi c'est important
Les modifications des bons de commande représentent du retravail et peuvent indiquer des problèmes de précision de la commande initiale ou des besoins commerciaux changeants. L'analyse de la fréquence et de la nature de ces changements aide à identifier les opportunités d'améliorer l'efficacité du processus.
Où obtenir
Cet événement est explicitement capturé lorsqu'une nouvelle révision de document est créée. Ceci peut être identifié par une augmentation du champ REVISION_NUM dans la table PO_HEADERS_ALL.
Capture
Identifiez chaque instance où le REVISION_NUM pour un PO_HEADER_ID augmente.
Type d'événement
explicit
|
|||
|
Commande d'achat rejetée
|
Un approbateur a rejeté la commande d'achat, la renvoyant au créateur pour révision. C'est un event explicite enregistré dans l'historique des actions, indiquant une rupture dans le flux de processus standard. | ||
|
Pourquoi c'est important
Les rejets introduisent des retouches et des retards dans le processus. Le suivi de cette activité aide à identifier les raisons courantes de rejet, les besoins en formation ou les exigences d'approbation peu claires.
Où obtenir
Cette action est enregistrée dans la table PO_ACTION_HISTORY avec un ACTION_CODE de « REJECT » pour le PO_HEADER_ID correspondant.
Capture
Filtrez PO_ACTION_HISTORY pour ACTION_CODE = 'REJECT'.
Type d'événement
explicit
|
|||
|
Commande d'achat soumise
|
Le bon de commande créé est soumis au workflow d'approbation. Oracle Fusion enregistre explicitement cette action, en capturant l'utilisateur et l'horodatage de la 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 identifier les goulots d'étranglement au sein du processus d'approbation interne.
Où obtenir
Cette action est enregistrée dans la table PO_ACTION_HISTORY avec un ACTION_CODE de « SUBMIT » pour le PO_HEADER_ID correspondant.
Capture
Filtrez PO_ACTION_HISTORY pour ACTION_CODE = 'SUBMIT'.
Type d'événement
explicit
|
|||
|
Demande d'achat approuvée
|
La demande d'achat a été approuvée par l'autorité désignée, autorisant le service des approvisionnements à créer un bon de commande. Cet événement est explicitement enregistré dans l'historique des actions du système concernant cette demande. | ||
|
Pourquoi c'est important
Ce jalon marque la fin du processus d'approbation interne de la demande. Les retards à ce stade peuvent avoir un impact direct sur le calendrier d'approvisionnement global, le suivi de sa durée est donc crucial.
Où obtenir
Cet événement est enregistré dans l'historique des actions associé à la demande d'achat, généralement suivi via les tables de workflow ou les champs de statut d'approbation spécifiques sur le document de demande d'achat.
Capture
Enregistré comme action d'approbation dans l'historique du workflow`` pour le document de réquisition spécifique.
Type d'événement
explicit
|
|||
|
Demande d'achat créée
|
Cette activité marque la création d'une demande d'achat, qui est la demande formelle de biens ou services précédant un bon de commande. Elle est enregistrée lorsqu'une nouvelle entrée est créée dans la table d'en-tête de la demande au sein d'Oracle Fusion. | ||
|
Pourquoi c'est important
L'analyse de cette activité permet de comprendre la phase d'origine de la demande. Le suivi du temps entre la demande d'approvisionnement et la création de la commande d'achat révèle des retards potentiels dans la conversion de la demande interne en ordres d'approvisionnement exploitables.
Où obtenir
Il s'agit d'un événement explicite enregistré lors de la sauvegarde d'une nouvelle demande. Il peut être trouvé en suivant l'horodatage de création dans la table POR_REQUISITION_HEADERS_ALL.
Capture
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
|
|||
|
Inspection qualité effectuée
|
Les marchandises nécessitant un contrôle qualité ont été inspectées et soit acceptées, soit rejetées. Cette activité a lieu après la réception initiale et est enregistrée comme une transaction distincte. | ||
|
Pourquoi c'est important
Cette activité est cruciale pour la gestion de la qualité. L'analyse de la durée des inspections aide à rationaliser le processus de contrôle qualité et à réduire les retards dans la mise à disposition des biens pour utilisation.
Où obtenir
Cet événement est enregistré dans la table RCV_TRANSACTIONS. Il est identifié par des transactions avec un TRANSACTION_TYPE de 'ACCEPTATION' ou 'REJET' qui font suite à une transaction de réception.
Capture
Utilisez le TRANSACTION_DATE de RCV_TRANSACTIONS lorsque le TRANSACTION_TYPE est 'ACCEPTATION' ou 'REJET'.
Type d'événement
explicit
|
|||
|
Marchandises retournées au fournisseur
|
Les marchandises précédemment reçues sont renvoyées au fournisseur, généralement en raison de défauts, de dommages ou d'expéditions incorrectes. Ceci 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é des fournisseurs et la précision des commandes. Des taux de retour élevés pour un fournisseur peuvent indiquer des problèmes systémiques qui doivent être traités.
Où obtenir
Il s'agit d'un événement explicite enregistré dans la table RCV_TRANSACTIONS avec un TRANSACTION_TYPE de 'RETOUR AU FOURNISSEUR'.
Capture
Utilisez le TRANSACTION_DATE de RCV_TRANSACTIONS lorsque le TRANSACTION_TYPE est 'RETOUR AU FOURNISSEUR'.
Type d'événement
explicit
|
|||
|
Réception de marchandises créée
|
Un document de réception est initié 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
Cet événement marque la transition des achats à la logistique. L'analyse du temps écoulé 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ù obtenir
Il s'agit d'un événement explicite, capturé par l'horodatage de création d'un nouvel enregistrement dans la table RCV_SHIPMENT_HEADERS lié au bon de commande.
Capture
Utilisez la date de création de l'enregistrement correspondant dans RCV_SHIPMENT_HEADERS.
Type d'événement
explicit
|
|||
|
Services livrés confirmés
|
Pour les commandes d'achat basées sur des services, cette activité marque la confirmation que les services ont été rendus comme convenu. Cette confirmation est souvent enregistrée manuellement ou via une feuille de saisie de services. | ||
|
Pourquoi c'est important
Il s'agit de l'équivalent d'une réception de marchandises pour les services et constitue une étape critique avant le paiement d'une facture. Les retards dans la confirmation de service peuvent entraîner des paiements tardifs et des relations tendues avec les fournisseurs.
Où obtenir
Cet événement est généralement capturé comme une réception associée à une ligne de service sur le PO. Il peut impliquer des champs spécifiques ou des réceptions complexes qui suivent la progression ou l'achèvement des services.
Capture
Identifiez les transactions de réception (RCV_TRANSACTIONS) liées aux lignes de commande d'achat basées sur des services.
Type d'événement
explicit
|
|||