Votre modèle de données pour le processus Achat au Paiement - Bon de Commande
Votre modèle de données pour le processus Achat au Paiement - Bon de Commande
- `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
De l'achat au paiement - Attributs des bons de commande
| Nom | Descriptionn | ||
|---|---|---|---|
|
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. | ||
|
Descriptionn
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 constitue le fondement du Process Mining. Elle permet de visualiser la cartographie des processus, d'identifier les points de blocage, de détecter les écarts par rapport à la procédure standard et de mesurer la durée des étapes spécifiques.
Pourquoi est-ce important ? :
Les activités sont les éléments constitutifs de la cartographie des processus. Leur suivi facilite la visualisation et l'analyse du flux de processus, des points de blocage et des écarts.
Source des données :
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. | ||
|
Descriptionn
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 complet 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és par cet identifiant aide à comprendre les variations de processus, les temps de cycle et la conformité pour les commandes individuelles.
Pourquoi est-ce 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.
Source des données :
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. | ||
|
Descriptionn
Cet attribut consigne la date et l'heure exactes pour chaque activité dans le processus. Il est indispensable pour l'ordonnancement chronologique des événements et pour toutes les analyses temporelles. 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 indispensable pour les dashboards liés au temps de cycle et à la performance.
Pourquoi est-ce important ? :
Cet horodatage est indispensable 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 points de blocage.
Source des données :
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. | ||
|
Descriptionn
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 paiement à temps. Cet attribut est indispensable pour le calcul du KPI 'Taux de paiement à 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 est-ce 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.
Source des données :
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. | ||
|
Descriptionn
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 impératif pour comparer la performance, identifier les points de blocage spécifiques à un département et comprendre les variations dans l'exécution du processus dans 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 est-ce important ? :
Permet de filtrer et de comparer la performance des processus danss différentes unités commerciales, révélant des problèmes spécifiques à chaque département ou les meilleures pratiques.
Source des données :
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 la fin d'une activité. Souvent le même que l'Heure de début pour les événements atomiques. | ||
|
Descriptionn
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 indispensable 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 est-ce important ? :
Permet le calcul des temps de traitement précis des activités, ce qui est indispensable pour analyser l'efficacité des ressources et identifier les tâches chronophages.
Source des données :
Peut être identique à l'Heure de début pour les événements atomiques ou dérivé des horodatages d'événements subséquents. Pour certaines activités, un horodatage 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. | ||
|
Descriptionn
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 est-ce 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.
Source des données :
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. | ||
|
Descriptionn
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 indispensablele 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 points de blocage, 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 est-ce important ? :
Identifie les individus dans la chaîne d'approbation, permettant d'analyser les points de blocage d'approbation, la charge de travail et les temps de cycle par approbateur.
Source des données :
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. | ||
|
Descriptionn
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 paiement à temps et examiner le taux de retour de marchandises pour identifier les fournisseurs performants ou peu performants. Ces données sont indispensables pour la gestion des relations fournisseurs et l'approvisionnement stratégique.
Pourquoi est-ce important ? :
Primordial 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.
Source des données :
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é. | ||
|
Descriptionn
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 (BC) 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 indispensablele pour le tableau de bord 'Charge de travail des ressources d'approbation' et pour enquêter sur les problèmes de conformité liés aux actions des utilisateurs.
Pourquoi est-ce 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.
Source des données :
Joindre aux tables utilisateur sur la base des identifiants dans des champs tels que CREATED_BY ou LAST_UPDATED_BY dans 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 ». | ||
|
Descriptionn
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 contribue directement au le tableau de bord « Taux de retour des marchandises et raisons » en permettant d'analyser les catégories les plus fréquemment retournées.
Pourquoi est-ce important ? :
Permet l'analyse des processus par type de dépense, ce qui peut révéler différents chemins de processus, points de blocage, ou taux de retour pour différentes catégories de marchandises.
Source des données :
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. | ||
|
Descriptionn
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 est-ce important ? :
Relie le bon de commande à la demande initiale, permettant une vue de processus complet plus complète, de la réquisition au paiement.
Source des données :
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
|
Heure de la dernière extraction ou actualisation des `données` depuis le système source. | ||
|
Descriptionn
Cet attribut indique la réactualisation 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 fondamentale 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 est-ce important ? :
Offre une transparence sur la réactualisation des données, garantissant que les utilisateurs comprennent à quel point l'analyse du processus est à jour.
Source des données :
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
|
|||
|
Est un reprises
IsRework
|
Un indicateur signalant si le bon de commande a été modifié après sa création initiale. | ||
|
Descriptionn
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 repriseslées. Comprendre les caractéristiques des commandes repriseslé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 est-ce important ? :
Prend directement en charge le KPI « Taux de modification des commandes d'achat » « what-if »mplifie l'analyse de l'instabilité des processus en signalant toutes les commandes ayant subi des modifications.
Source des données :
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. | ||
|
Descriptionn
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 indispensable 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 est-ce 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.
Source des données :
Champ calculé. Défini sur 'vrai' si l'horodatage de 'Commande d'achat approuvée' est inférieur ou égal au horodatage de 'Commande d'achat envoyée au fournisseur'.
Exemples
truefaux
|
|||
|
Lieu de livraison
DeliveryLocation
|
L'emplacement physique ou l'adresse de livraison des biens. | ||
|
Descriptionn
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 tableau de bord '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 est-ce important ? :
Permet d'analyser les performances par emplacement géographique, aidant à identifier les points de blocage régionaux ou spécifiques aux sites dans le processus de réception des marchandises.
Source des données :
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. | ||
|
Descriptionn
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 terminées. Il est indispensable pour le tableau de bord 'Flux et statut des commandes d'achat'.
Pourquoi est-ce 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.
Source des données :
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. | ||
|
Descriptionn
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 indispensablele 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 est-ce important ? :
Identifie l'origine des données, ce qui est impératif pour la gouvernance des données, le contexte et l'intégration avec d'autres systèmes.
Source des données :
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 ». | ||
|
Descriptionn
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 est-ce 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.
Source des données :
Oracle Fusion Cloud SCM, table PO_HEADERS_ALL, colonne TYPE_LOOKUP_CODE.
Exemples
STANDARDCOMMANDE-CADRECONTRAT
|
|||
|
Unité commerciale
BusinessUnitName
|
La Business Unit spécifique dans l'organisation qui effectue l'achat. | ||
|
Descriptionn
La Business Unit représente une entité métier distincte dans 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 indispensablele 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 est-ce important ? :
Primordial pour les grandes organisations de comparer l'efficacité des processus et la conformité entre les différentes divisions opérationnelles.
Source des données :
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. | ||
|
Descriptionn
Cet attribut booléen calculé est vrai si l'horodatage 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 paiement à 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 est-ce important ? :
Prend directement en charge le KPI « Taux de paiement à temps », permettant une analyse claire de la performance des fournisseurs et de la fiabilité des livraisons.
Source des données :
Champ calculé. Défini sur 'vrai' si l'horodatage de l'activité 'Marchandises reçues' est postérieur à l'attribut 'Date de livraison demandée'.
Exemples
truefaux
|
|||
De l'achat au paiement - Activités des bons de commande
| Activité | Descriptionn | ||
|---|---|---|---|
|
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 est-ce 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.
Source des données :
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
|
|||
|
Bon de commande envoyé 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 horodatage sur l'enregistrement de communication de la commande d'achat. | ||
|
Pourquoi est-ce important ? :
Cet événement marque le début du délai de livraison du fournisseur. C'est un point essentiel pour mesurer la performance du fournisseur, de l'accusé de réception à la livraison finale.
Source des données :
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 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 est-ce important ? :
C'est un jalon critique qui conditionne l'envoi du PO au fournisseur. Il est indispensable pour mesurer les temps de cycle d'approbation et garantir la conformité aux politiques de dépenses.
Source des données :
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 est-ce important ? :
En tant qu'event de départ principal pour le cas de la commande d'achat, cette activité est clée 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.
Source des données :
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 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 est-ce 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 indispensable pour mesurer le débit global du processus et les taux d'achèvement.
Source des données :
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 est-ce 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.
Source des données :
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 est-ce 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.
Source des données :
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 est-ce important ? :
Les modifications des bons de commande représentent du reprises et peuvent indiquer des problèmes de prélèvement.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.
Source des données :
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 est-ce 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.
Source des données :
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 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 indispensablele pour identifier les points de blocage au sein du processus d'approbation interne.
Source des données :
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 est-ce 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.
Source des données :
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
Comptabilisé 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 est-ce 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.
Source des données :
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 est-ce important ? :
Cette activité est indispensablele 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.
Source des données :
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 est-ce important ? :
Le suivi des retours est indispensable 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.
Source des données :
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 est-ce 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.
Source des données :
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 est-ce 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.
Source des données :
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
|
|||