Votre modèle de données Order to Cash - Sales Order Processing
Votre modèle de données Order to Cash - Sales Order Processing
- Attributs recommandés à collecter
- Activités clés à suivre pour l’analyse
- Conseils pour l’extraction des données
Order to Cash, attributs du traitement des commandes clients
| Nom | Description | ||
|---|---|---|---|
|
Commande client
SalesOrder
|
Identifiant unique de la commande client, qui constitue le dossier principal du processus Order to Cash. | ||
|
Description
Le numéro de commande client identifie de manière unique chaque commande tout au long de son cycle de vie, de sa création à sa clôture finale. Il constitue le fil conducteur reliant toutes les activités associées, comme l’enregistrement, l’expédition, la facturation et le paiement. Dans le Process Mining, cet attribut est essentiel pour reconstituer le parcours complet de chaque commande. En regroupant tous les événements sous une même commande client, les analystes peuvent visualiser le flux complet du processus, repérer les variations entre les commandes et mesurer des indicateurs de performance clés, comme la durée du cycle et le taux de livraison dans les délais, pour chaque dossier.
Pourquoi c’est important
Il s’agit du Case ID, indispensable pour relier tous les événements du processus et analyser le cycle de vie complet de la commande.
Où les obtenir
Clé primaire d’une commande client, généralement présente dans les tables Oracle Order Management, par exemple OE_ORDER_HEADERS_ALL.HEADER_ID.
Exemples
685127103482459
|
|||
|
Heure de l’événement
EventTime
|
Horodatage indiquant le moment où une activité donnée s’est produite. | ||
|
Description
Event Time, ou horodatage, indique la date et l’heure précises auxquelles une activité a été exécutée. Il enregistre par exemple le moment où une commande a été créée, où une facture a été envoyée ou où un paiement a été reçu. Ces données temporelles sont fondamentales pour le Process Mining. Cet attribut sert à classer chronologiquement les événements de chaque cas, ce qui est nécessaire pour reconstituer fidèlement le flux du processus. Il constitue également la base de tous les calculs de durée et de performance, comme les temps de cycle entre les activités, la durée globale d’un cas et l’identification des délais ou des goulots d’étranglement.
Pourquoi c’est important
Fournit la séquence chronologique des événements et constitue la base de toutes les analyses de performance fondées sur le temps, notamment le temps de cycle et l’identification des goulots d’étranglement.
Où les obtenir
Provient de différents champs de date des tables Oracle EBS, comme CREATION_DATE dans OE_ORDER_HEADERS_ALL, ACTUAL_SHIPMENT_DATE dans WSH_DELIVERY_DETAILS ou TRX_DATE dans RA_CUSTOMER_TRX_ALL.
Exemples
2023-04-15T10:30:00Z2023-04-18T14:00:00Z2023-05-01T09:15:00Z
|
|||
|
Nom de l’activité
ActivityName
|
Nom d’un événement ou d’une étape métier précis survenu au cours du cycle de vie de la commande client. | ||
|
Description
Cet attribut enregistre le nom de chaque activité effectuée sur une commande client, comme « Order Booked », « Goods Shipped » ou « Payment Received ». Ces activités représentent les principales étapes du processus Order to Cash. L’analyse de la séquence et de la fréquence de ces activités constitue le cœur du Process Mining. Elle permet de découvrir les flux réels du processus, notamment les parcours fréquents, les écarts et les goulots d’étranglement. Ces données servent à générer la carte du processus, principale représentation visuelle utilisée pour analyser le processus.
Pourquoi c’est important
Définit les étapes de la cartographie du processus, indispensable pour visualiser et analyser le flux du processus.
Où les obtenir
Il s’agit d’un champ conceptuel dérivé de différents événements, statuts et dates de transaction des systèmes sources, dans des modules tels qu’Order Management, Shipping Execution et Accounts Receivable.
Exemples
Commande client crééeMarchandises expédiéesFacture crééePaiement reçu
|
|||
|
Conditions de paiement
PaymentTerms
|
Conditions convenues qui définissent la date à laquelle le client doit payer les marchandises ou les services. | ||
|
Description
Les conditions de paiement précisent les modalités de règlement d’une facture, par exemple « Net 30 », « Net 60 » ou « Due on Receipt ». Cet attribut est fondamental pour gérer les créances clients et la trésorerie. L’analyse de la performance du processus selon les conditions de paiement aide à déterminer si les clients bénéficiant de certaines conditions sont davantage susceptibles de payer en retard. Ces informations servent à évaluer le risque financier, à optimiser les stratégies de recouvrement et à mesurer l’efficacité des différentes conditions proposées. Il s’agit d’une dimension essentielle du Dashboard « Payment Terms Compliance Monitoring ».
Pourquoi c’est important
Essentiel pour analyser les comportements de paiement, suivre la trésorerie et évaluer le risque financier associé aux différents accords conclus avec les clients.
Où les obtenir
Se trouve dans la table RA_TERMS, reliée par TERM_ID à des tables telles que RA_CUSTOMER_TRX_ALL pour les factures ou OE_ORDER_HEADERS_ALL pour les commandes.
Exemples
À 30 joursÀ 60 joursPayable à réception
|
|||
|
Date d’échéance du paiement
PaymentDueDate
|
Date calculée à laquelle le paiement de la facture doit être reçu du client. | ||
|
Description
La date d’échéance du paiement est la date calendaire à laquelle une facture doit être réglée. Elle est calculée à partir de la date de facture et des conditions de paiement convenues. Elle constitue la date cible de l’activité « Payment Received ». Cet attribut est essentiel pour calculer le KPI « Payment Term Compliance Rate » en le comparant à la date réelle de paiement. L’analyse des écarts aide l’équipe de recouvrement à hiérarchiser ses efforts, à identifier les clients qui paient régulièrement en retard et à mesurer l’efficacité du processus de relance.
Pourquoi c’est important
Sert de date cible pour le recouvrement des paiements et permet de mesurer la ponctualité des règlements ainsi que le respect des conditions par les clients.
Où les obtenir
Se trouve dans le champ DUE_DATE de la table AR_PAYMENT_SCHEDULES_ALL, qui est reliée à la transaction de facturation.
Exemples
2023-06-152023-07-012023-08-30
|
|||
|
Date de livraison confirmée
ConfirmedDeliveryDate
|
Date convenue à laquelle les marchandises doivent être livrées au client. | ||
|
Description
Cet attribut enregistre la date de livraison promise ou confirmée au client. Il sert de référence pour mesurer la performance des livraisons dans les délais. Dans le Process Mining, cette date est comparée à l’horodatage réel de livraison, issu de l’activité « Goods Delivered », afin de calculer le KPI « On-Time Delivery Rate ». L’analyse des écarts par rapport à cette date aide à identifier les problèmes systémiques liés à la logistique, à la gestion des stocks ou à la planification de la production, qui entraînent des retards de livraison.
Pourquoi c’est important
Constitue la référence pour mesurer la performance des livraisons dans les délais, un KPI important pour la satisfaction client et l’excellence opérationnelle.
Où les obtenir
Cette date se trouve généralement dans les champs LATEST_ACCEPTABLE_DATE ou REQUEST_DATE au niveau de la ligne de commande, dans la table OE_ORDER_LINES_ALL.
Exemples
2023-05-102023-06-012023-07-20
|
|||
|
Montant total de la commande
TotalOrderAmount
|
Valeur monétaire totale de la commande client. | ||
|
Description
Cet attribut représente la valeur totale de toutes les lignes d’une commande client, exprimée dans la devise de la transaction. Il s’agit d’un indicateur financier important associé à chaque cas. L’analyse des indicateurs du processus par montant de commande permet de hiérarchiser les efforts d’amélioration. Les analystes peuvent notamment vérifier si les commandes de valeur élevée connaissent davantage de délais ou de reprises que les commandes de faible valeur. Cette analyse permet également d’évaluer l’impact financier, par exemple en mesurant la valeur des commandes bloquées dans un goulot d’étranglement donné.
Pourquoi c’est important
Permet une analyse financière du processus, en aidant à prioriser les commandes de forte valeur et à quantifier l’impact financier des inefficacités.
Où les obtenir
Cette valeur est généralement calculée en additionnant les montants des lignes d’une commande donnée. Les montants des lignes se trouvent dans des tables telles que OE_ORDER_LINES_ALL.
Exemples
5450.00125000.75980.50
|
|||
|
Nom de l’utilisateur
UserName
|
Utilisateur ayant effectué l’activité. | ||
|
Description
Identifie l’utilisateur chargé d’exécuter une étape donnée du processus. Il peut s’agir du commercial qui a créé la commande, de l’analyste crédit qui a effectué le contrôle ou du gestionnaire qui a créé la facture. L’analyse des activités par utilisateur aide à repérer les besoins de formation, les personnes ou équipes les plus performantes et la répartition de la charge de travail. Elle est également essentielle pour la conformité et l’analyse de la piste d’audit, notamment pour examiner des actions non autorisées ou comprendre les schémas de reprise associés à certains utilisateurs.
Pourquoi c’est important
Permet d’analyser la performance des utilisateurs, la répartition de la charge de travail et le respect des protocoles de conformité. Il aide à répondre à la question « qui » a effectué une action.
Où les obtenir
Provient de champs liés aux utilisateurs, comme CREATED_BY ou LAST_UPDATED_BY, dans différentes tables Oracle EBS. Il est souvent nécessaire d’effectuer une jointure avec FND_USER pour obtenir le nom complet de l’utilisateur.
Exemples
JSMITHRWILLIAMSCDAVIS
|
|||
|
Nom du client
CustomerName
|
Nom du client ayant passé la commande. | ||
|
Description
Cet attribut identifie la dénomination légale du client associé à la commande. Il constitue une dimension principale pour segmenter et analyser la performance du processus. En filtrant le processus ou en le ventilant par client, les analystes peuvent identifier les clients qui connaissent les durées de cycle les plus longues, les taux de reprise les plus élevés ou les retards de paiement les plus fréquents. Ces informations sont très utiles pour améliorer la relation client, adapter les niveaux de service et comprendre le comportement des clients.
Pourquoi c’est important
Permet une analyse centrée sur le client afin d’identifier les écarts de performance, d’améliorer le service et de comprendre les comportements de paiement selon les clients.
Où les obtenir
Est dérivé d’une jointure entre SOLD_TO_ORG_ID dans OE_ORDER_HEADERS_ALL et les tables HZ_CUST_ACCOUNTS et HZ_PARTIES afin de récupérer le nom de la partie.
Exemples
Global Tech Inc.Innovate Solutions LLCPioneer Corp
|
|||
|
Statut de la commande
OrderStatus
|
Statut actuel ou historique de la commande client ou de la ligne de commande. | ||
|
Description
Cet attribut enregistre le statut d’une commande client à différents moments, par exemple « Entered », « Booked », « Closed » ou « Cancelled ». Les statuts correspondent souvent directement aux activités du processus. Le suivi du statut des commandes est essentiel pour créer des Dashboards présentant l’état actuel de toutes les commandes actives. Il permet aux responsables de surveiller le portefeuille de commandes, de repérer les commandes bloquées et de gérer les exceptions de manière proactive. L’analyse des transitions de statut constitue une méthode courante pour définir les activités de la cartographie du processus.
Pourquoi c’est important
Fournit une visibilité sur le portefeuille de commandes clients, en aidant à repérer les commandes bloquées et à gérer les exceptions du processus.
Où les obtenir
Se trouve généralement dans la colonne FLOW_STATUS_CODE des tables OE_ORDER_HEADERS_ALL et OE_ORDER_LINES_ALL.
Exemples
EnregistréeEn attente d'expéditionExpédiéeClôturéeAnnulée
|
|||
|
Avec reprise
IsRework
|
Indicateur précisant si une commande client a fait l’objet d’une reprise, par exemple à la suite d’activités répétées de confirmation ou de mise à jour. | ||
|
Description
Il s’agit d’un attribut booléen calculé qui signale les cas présentant des schémas caractéristiques d’une reprise. Celle-ci peut être identifiée en détectant des boucles dans la cartographie du processus, par exemple lorsqu’une commande est enregistrée plusieurs fois, ou en repérant certains événements de modification consignés dans le système. Cet indicateur sert à calculer le KPI « Taux de reprise des commandes clients » et à alimenter le Dashboard « Analyse des reprises de commandes clients ». Les analystes peuvent ainsi isoler et étudier les commandes qui s’écartent du processus standard, mesurer l’incidence des reprises sur les délais de traitement et les coûts, puis identifier les causes profondes de ces boucles inefficaces.
Pourquoi c’est important
Aide à mesurer l’inefficacité du processus en signalant les commandes ayant nécessité des modifications manuelles, afin d’analyser les causes et les effets des reprises.
Où les obtenir
Calculé lors de la transformation des données, en identifiant les séquences d’activités qui correspondent à une boucle, par exemple lorsque « Order Booked » se produit plusieurs fois pour le même cas.
Exemples
truefalse
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Horodatage de l’actualisation la plus récente des données provenant du système source. | ||
|
Description
Cet attribut indique la dernière fois que les données ont été extraites d’Oracle E-Business Suite et chargées dans l’outil de Process Mining. Il reflète l’actualité des données analysées. Il est essentiel que les utilisateurs puissent évaluer la fraîcheur des analyses qu’ils consultent. Il leur permet de savoir s’ils examinent des informations en temps réel ou un instantané correspondant à un moment précis, ce qui est important pour prendre des décisions opérationnelles.
Pourquoi c’est important
Informe les utilisateurs sur la fraîcheur des données, un élément essentiel pour accorder sa confiance à l’analyse et prendre des décisions au bon moment.
Où les obtenir
Cet horodatage est généré et ajouté lors du processus d’extraction, de transformation et de chargement (ETL) des données.
Exemples
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Devise
Currency
|
Code devise utilisé pour les montants de la commande client. | ||
|
Description
L’attribut de devise précise la devise dans laquelle les montants de la commande sont exprimés, par exemple USD, EUR ou JPY. Il fournit le contexte nécessaire à l’interprétation des données financières associées à la commande. Il est essentiel pour les analyses menées dans les organisations internationales qui utilisent plusieurs devises. Il garantit une interprétation correcte des indicateurs financiers tels que « Total Order Amount » et permet, si nécessaire, d’effectuer les conversions de devises pour les rapports consolidés.
Pourquoi c’est important
Fournit le contexte nécessaire à l’interprétation de toutes les valeurs monétaires et garantit la fiabilité de l’analyse financière, notamment dans un environnement international.
Où les obtenir
Se trouve dans le champ TRANSACTIONAL_CURR_CODE de la table OE_ORDER_HEADERS_ALL.
Exemples
USDEURGBP
|
|||
|
Livraison dans les délais
IsOnTimeDelivery
|
Indicateur précisant si la commande a été livrée à la date de livraison confirmée ou avant celle-ci. | ||
|
Description
Cet attribut calculé est un indicateur booléen (True/False) qui précise si la commande a respecté l’engagement de livraison. Il est obtenu en comparant l’horodatage de l’activité « Goods Delivered » à la « Confirmed Delivery Date ». Cet attribut contribue directement au KPI « Taux de livraison dans les délais ». Il simplifie l’analyse et la création de Dashboards en fournissant un résultat binaire clair pour chaque commande. Vous pouvez ainsi filtrer et agréger facilement les données afin d’identifier les caractéristiques des livraisons en retard, comme les produits, les clients ou les modes d’expédition fréquemment concernés.
Pourquoi c’est important
Mesure directement le niveau de service client et la fiabilité de l’exécution, tout en simplifiant le calcul et la visualisation du KPI de livraison dans les délais.
Où les obtenir
Il s’agit d’un champ calculé. La logique est la suivante : IF ('Goods Delivered' EventTime <= ConfirmedDeliveryDate) THEN True ELSE False.
Exemples
truefalse
|
|||
|
Mode d’expédition
ShippingMethod
|
Mode de transport ou transporteur utilisé pour acheminer les marchandises au client. | ||
|
Description
Cet attribut précise le mode de transport ou le niveau de service utilisé pour l’expédition, par exemple « Ground Freight », « Air Express » ou « Local Courier ». Il influence directement le délai et le coût de livraison. En analysant le processus selon cet attribut, les entreprises peuvent évaluer la performance des différents modes d’expédition. Par exemple, le Dashboard « Shipping Method Performance » compare la durée entre « Goods Shipped » et « Goods Delivered » pour chaque mode, afin d’optimiser la logistique en conciliant rapidité, coût et fiabilité.
Pourquoi c’est important
Permet d’évaluer la performance des différents transporteurs et modes d’expédition afin d’optimiser les coûts, la rapidité et la fiabilité.
Où les obtenir
Est généralement stocké sous SHIPPING_METHOD_CODE dans des tables telles que WSH_DELIVERY_DETAILS ou OE_ORDER_LINES_ALL.
Exemples
UPS GroundFedEx Priority OvernightDHL Express Worldwide
|
|||
|
Motif de l’annulation
CancellationReason
|
Motif documenté de l’annulation d’une commande client ou d’une ligne de commande. | ||
|
Description
Lorsqu’une commande client est annulée, cet attribut enregistre le motif indiqué pour l’annulation. Les motifs peuvent notamment être « Demande du client », « Rupture de stock » ou « Blocage de crédit ». Ces données sont essentielles à l’analyse des causes profondes des annulations de commandes. Le Dashboard « Taux et motifs d’annulation des commandes clients » utilise cet attribut pour identifier les principaux facteurs d’annulation. L’entreprise peut ainsi mettre en place des mesures ciblées afin de réduire l’attrition, d’améliorer les prévisions de stocks ou d’affiner ses politiques de crédit.
Pourquoi c’est important
Fournit une visibilité directe sur les raisons des annulations de commandes, afin d’analyser leurs causes profondes, de réduire les ventes perdues et d’améliorer la fidélisation des clients.
Où les obtenir
Ces informations sont généralement stockées dans un champ de code motif, tel que CANCELLED_REASON, qui peut être disponible dans la table OE_ORDER_LINES_ALL ou dans une table associée aux modifications de commandes.
Exemples
Article arrêtéAnnulation par le clientCommande en double
|
|||
|
Numéro de produit
ProductNumber
|
Identifiant unique du produit ou de l’article figurant sur la ligne de commande client. | ||
|
Description
Cet attribut identifie précisément le matériau, l’article ou le service vendu. Il permet d’effectuer des analyses à un niveau plus détaillé que celui de l’en-tête de commande. L’analyse du processus par produit permet de mettre au jour des problèmes propres à certains produits. Par exemple, certains produits peuvent présenter des délais d’exécution plus longs en raison de leur fabrication ou de leur approvisionnement complexes, tandis que d’autres peuvent être associés à un taux plus élevé d’erreurs d’expédition ou de litiges clients. Vous pouvez ainsi cibler les améliorations à apporter à la chaîne d’approvisionnement et à la gestion des produits.
Pourquoi c’est important
Permet d’analyser les produits afin d’identifier ceux qui entraînent des retards, des reprises ou d’autres inefficacités dans le processus.
Où les obtenir
Dérivé de INVENTORY_ITEM_ID dans la table OE_ORDER_LINES_ALL, qui peut être relié à MTL_SYSTEM_ITEMS_B pour obtenir le numéro ou la description de l’article.
Exemples
AS54888CM15001SV20100
|
|||
|
Paiement dans les délais
IsPaymentOnTime
|
Indicateur précisant si le paiement a été reçu à la date d’échéance de la facture ou avant celle-ci. | ||
|
Description
Il s’agit d’un attribut booléen calculé en comparant l’horodatage de l’activité « Payment Received » à la « Payment Due Date » de la facture correspondante. Il fournit un indicateur simple True/False du respect des conditions de paiement. Cet indicateur constitue la base du KPI « Taux de respect des conditions de paiement ». Il simplifie la création de Dashboards et de rapports consacrés au comportement de paiement des clients et à l’efficacité du processus de recouvrement. Vous pouvez rapidement distinguer les paiements effectués dans les délais des paiements en retard afin d’analyser les facteurs concernés, comme le type de client ou les conditions de paiement.
Pourquoi c’est important
Mesure directement le respect des conditions de paiement, un élément essentiel pour gérer la trésorerie et évaluer la fiabilité financière des clients.
Où les obtenir
Il s’agit d’un champ calculé. La logique est la suivante : IF ('Payment Received' EventTime <= PaymentDueDate) THEN True ELSE False.
Exemples
truefalse
|
|||
|
Quantité commandée
OrderQuantity
|
Quantité de produit commandée sur une ligne donnée de commande client. | ||
|
Description
Cet attribut indique le nombre d’unités d’un produit donné demandé par le client sur une ligne de commande. Il représente le volume de la transaction au niveau de la ligne. La quantité commandée peut servir de dimension d’analyse pour déterminer si le comportement du processus varie selon la taille de la commande. Par exemple, les commandes très importantes ou très faibles peuvent suivre des parcours différents ou subir des retards de nature différente. Elle apporte également un contexte utile à d’autres indicateurs, comme la valeur de la commande.
Pourquoi c’est important
Donne une indication sur l’ampleur d’une commande et permet d’analyser l’incidence du volume commandé sur l’efficacité du processus et les parcours d’exécution.
Où les obtenir
Disponible dans le champ ORDERED_QUANTITY de la table OE_ORDER_LINES_ALL.
Exemples
102501
|
|||
|
Système source
SourceSystem
|
Système depuis lequel les données ont été extraites. | ||
|
Description
Cet attribut identifie le système d’information source à l’origine des données d’événements. Pour ce processus, sa valeur sera toujours « Oracle E-Business Suite ». Dans les environnements comportant plusieurs systèmes, ce champ est essentiel pour assurer la traçabilité des données et faciliter le diagnostic. Même dans un contexte reposant sur un seul système, il fournit un contexte important pour le modèle de données et contribue à standardiser les processus d’ingestion des données.
Pourquoi c’est important
Fournit un contexte essentiel sur l’origine des données, en garantissant leur traçabilité et leur interprétation correcte, notamment dans les environnements multi-systèmes.
Où les obtenir
Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) pour identifier l’origine des données.
Exemples
Oracle E-Business SuiteOracle EBS R12
|
|||
Order to Cash, activités de traitement des commandes clients
| Activité | Description | ||
|---|---|---|---|
|
Commande client créée
|
Cette activité correspond à la création initiale d’une commande client dans le système. Il s’agit d’un événement explicite enregistré lorsqu’un utilisateur sauvegarde l’en-tête d’une nouvelle commande client, ce qui marque le début officiel du processus Order to Cash. | ||
|
Pourquoi c’est important
Il s’agit de l’événement de début principal du processus. L’analyse du délai entre ce point et les activités suivantes est essentielle pour mesurer la durée globale du cycle Order to Cash.
Où les obtenir
Cet événement est enregistré dans la table OE_ORDER_HEADERS_ALL du module Oracle Order Management. La colonne CREATION_DATE fournit l’horodatage explicite de cette activité.
Collecte
Utilisez CREATION_DATE dans la table OE_ORDER_HEADERS_ALL.
Type d’événement
explicit
|
|||
|
Commande clôturée
|
Cette activité marque la fin du traitement de la commande client, une fois que toutes ses lignes ont été expédiées, facturées et clôturées. Il s’agit d’une mise à jour explicite du statut de l’en-tête de commande. | ||
|
Pourquoi c’est important
Il s’agit du principal point de terminaison indiquant la réussite du processus Order to Cash. Il fournit l’horodatage final nécessaire au calcul de la durée du cycle de bout en bout pour les commandes exécutées avec succès.
Où les obtenir
Cet événement est enregistré dans la table OE_ORDER_HEADERS_ALL lorsque FLOW_STATUS_CODE est mis à jour avec la valeur « CLOSED ». LAST_UPDATE_DATE pour cette modification de statut constitue l’horodatage de l’événement.
Collecte
Horodatage de la mise à jour dans OE_ORDER_HEADERS_ALL lorsque FLOW_STATUS_CODE prend la valeur « CLOSED ».
Type d’événement
explicit
|
|||
|
Commande enregistrée
|
Cette étape correspond à la confirmation officielle de la commande client, qui devient alors active et peut faire l’objet des traitements suivants, comme l’approvisionnement et l’expédition. Il s’agit d’une action explicite dans Oracle EBS, qui fait passer le statut de la commande de « Entered » à « Booked ». | ||
|
Pourquoi c’est important
L’enregistrement de la commande constitue une étape essentielle, car il engage officiellement la commande pour son exécution. Les délais entre la création et l’enregistrement peuvent révéler des problèmes de saisie, d’approbation ou de validation initiale.
Où les obtenir
L’événement est enregistré dans la table OE_ORDER_HEADERS_ALL. Il se produit lorsque BOOKED_FLAG prend la valeur « Y », l’horodatage étant enregistré dans la colonne BOOKED_DATE.
Collecte
Utilisez BOOKED_DATE dans la table OE_ORDER_HEADERS_ALL.
Type d’événement
explicit
|
|||
|
Facture créée
|
Cet événement marque la création de la facture client pour les marchandises expédiées. Il s’agit d’un événement explicite déclenché par le processus AutoInvoice, qui transfère les données d’Order Management et de Shipping vers le module Receivables. | ||
|
Pourquoi c’est important
Cette activité lance la phase de règlement financier du processus. Elle constitue le point de départ pour mesurer le délai entre la facturation et le paiement, ainsi que pour suivre l’efficacité de la facturation.
Où les obtenir
Il s’agit d’une transaction explicite enregistrée dans la table RA_CUSTOMER_TRX_ALL d’Oracle Receivables. TRX_DATE ou CREATION_DATE sert d’horodatage de l’événement.
Collecte
Utilisez TRX_DATE dans la table RA_CUSTOMER_TRX_ALL.
Type d’événement
explicit
|
|||
|
Marchandises expédiées
|
Cette activité correspond à la fin du processus de confirmation d’expédition, lorsque les marchandises quittent physiquement l’entrepôt. Il s’agit d’un événement explicite essentiel du module d’expédition, qui met à jour le stock et fait progresser le statut de la commande. | ||
|
Pourquoi c’est important
Cette étape essentielle de l’exécution sert à mesurer la performance des expéditions dans les délais. Elle déclenche également les processus de facturation et de comptabilisation du chiffre d’affaires.
Où les obtenir
L’événement est enregistré explicitement dans Oracle Shipping Execution. L’horodatage peut être trouvé dans la colonne INITIAL_PICKUP_DATE de la table WSH_NEW_DELIVERIES ou déduit des mises à jour du statut des détails de livraison dans WSH_DELIVERY_DETAILS, lorsque celui-ci passe à « Shipped ».
Collecte
Utilisez la date de confirmation d’expédition dans WSH_DELIVERY_DETAILS ou WSH_NEW_DELIVERIES.
Type d’événement
explicit
|
|||
|
Paiement reçu
|
Cette activité se produit lorsque le paiement d’un client est reçu et affecté à la facture correspondante dans le système. Il s’agit d’une transaction financière explicite enregistrée dans le module Accounts Receivable. | ||
|
Pourquoi c’est important
Cette étape est essentielle pour suivre la trésorerie, le délai moyen de règlement des clients (DSO) et le respect des conditions de paiement. Elle constitue un point de terminaison important pour mesurer la durée du cycle financier.
Où les obtenir
L’événement est enregistré explicitement dans la table AR_RECEIVABLE_APPLICATIONS_ALL. La colonne APPLY_DATE fournit l’horodatage auquel l’encaissement a été affecté à la facture.
Collecte
Utilisez APPLY_DATE dans AR_RECEIVABLE_APPLICATIONS_ALL pour la facture concernée.
Type d’événement
explicit
|
|||
|
Stock alloué
|
Cette activité correspond à la réservation du stock pour les lignes de commande, afin de garantir la disponibilité de la quantité nécessaire à la préparation. Elle est généralement déduite d’un changement de statut de la ligne de commande indiquant qu’elle peut être libérée vers l’entrepôt. | ||
|
Pourquoi c’est important
Cette étape est essentielle pour évaluer la préparation de l’exécution. Les délais à ce stade peuvent signaler des ruptures de stock, des problèmes d’approvisionnement ou des inefficacités dans le processus d’allocation.
Où les obtenir
L’événement est déduit des changements de statut dans la table WSH_DELIVERY_DETAILS. L’activité se produit lorsque le statut d’une ligne passe à « Ready to Release », l’horodatage étant dérivé de la mise à jour de statut correspondante.
Collecte
Déduit des mises à jour du statut des lignes dans WSH_DELIVERY_DETAILS, lorsque celui-ci passe à « Ready to Release ».
Type d’événement
inferred
|
|||
|
Commande annulée
|
Représente l’annulation d’une commande client complète avant la fin de son exécution. Il s’agit d’un événement explicite qui met fin au flux de travail de traitement de la commande. | ||
|
Pourquoi c’est important
Il s’agit d’un point de terminaison d’exception important. L’analyse de la fréquence, du moment et des motifs des annulations est essentielle pour identifier les pertes de chiffre d’affaires ainsi que les problèmes liés aux processus ou aux produits.
Où les obtenir
L’événement est enregistré dans la table OE_ORDER_HEADERS_ALL lorsque FLOW_STATUS_CODE prend la valeur « CANCELLED » et que CANCELLED_FLAG vaut « Y ». LAST_UPDATE_DATE peut être utilisé comme horodatage.
Collecte
Horodatage auquel CANCELLED_FLAG dans OE_ORDER_HEADERS_ALL prend la valeur « Y ».
Type d’événement
explicit
|
|||
|
Contrôle de solvabilité effectué
|
Cette activité indique que le contrôle de solvabilité du client pour la commande est terminé. Elle est souvent enregistrée lorsqu’un blocage lié au contrôle de solvabilité, s’il a été appliqué, est levé sur la commande client, ce qui permet de poursuivre le traitement. | ||
|
Pourquoi c’est important
Les délais liés aux contrôles de crédit constituent un goulot d’étranglement fréquent, susceptible de bloquer l’ensemble du processus d’exécution. Le suivi de cette activité permet d’identifier les inefficacités des contrôles financiers et des approbations.
Où les obtenir
Cet événement peut être déduit de la table OE_ORDER_HOLDS_ALL en identifiant l’horodatage auquel un « Credit Check Hold » est levé pour un en-tête de commande donné.
Collecte
Utilisez l’horodatage de levée des blocages liés au contrôle de solvabilité dans OE_ORDER_HOLDS_ALL.
Type d’événement
inferred
|
|||
|
Facture envoyée au client
|
Cette activité correspond au moment où la facture est transmise au client, par impression ou par voie électronique. Elle est généralement déduite, car elle ne constitue pas toujours un événement distinct et explicite de la création de la facture. | ||
|
Pourquoi c’est important
Elle marque le début officiel du délai de paiement accordé au client. Les retards entre la création et l’envoi de la facture peuvent nuire à la trésorerie et entraîner des paiements tardifs.
Où les obtenir
Cet événement peut être déduit de LAST_PRINTED_DATE dans la table RA_CUSTOMER_TRX_ALL. Pour les factures électroniques, il peut être nécessaire d’examiner les journaux d’un système externe de diffusion de documents.
Collecte
Utilisez LAST_PRINTED_DATE dans RA_CUSTOMER_TRX_ALL ou les journaux d’outils tiers.
Type d’événement
inferred
|
|||
|
Ligne de commande clôturée
|
Indique que le traitement de chaque ligne d’une commande client est terminé, y compris l’expédition et la facturation. Il s’agit d’un changement de statut explicite géré par le flux de travail. | ||
|
Pourquoi c’est important
Le suivi des clôtures au niveau des lignes aide à analyser les expéditions partielles et à repérer les problèmes liés à certains produits ou circuits d’exécution avant la clôture complète de la commande.
Où les obtenir
L’événement est enregistré dans la table OE_ORDER_LINES_ALL lorsque FLOW_STATUS_CODE est mis à jour avec la valeur « CLOSED ». LAST_UPDATE_DATE pour cette modification de statut peut servir d’horodatage.
Collecte
Horodatage de la mise à jour dans OE_ORDER_LINES_ALL lorsque FLOW_STATUS_CODE prend la valeur « CLOSED ».
Type d’événement
explicit
|
|||
|
Marchandises livrées
|
Cette activité indique que l’expédition est arrivée chez le client. Oracle EBS standard ne suit pas cet événement. Il doit donc généralement être déduit ou importé depuis les systèmes externes des transporteurs. | ||
|
Pourquoi c’est important
Cette information est essentielle pour mesurer les KPI de livraison dans les délais et comprendre l’expérience client dans son ensemble. L’écart entre l’expédition et la livraison met en évidence la performance du transporteur.
Où les obtenir
Une analyse du système est nécessaire. Ces données ne sont pas disponibles nativement dans Oracle EBS et doivent être obtenues à partir des flux de données de transporteurs externes ou de plateformes logistiques intégrées au système.
Collecte
Déduit des données externes du transporteur ou estimé à partir d’un délai de transit standard après « Goods Shipped ».
Type d’événement
inferred
|
|||
|
Préparation libérée
|
Cet événement marque le moment où les lignes de commande client sont libérées vers l’entrepôt afin que les opérations de préparation puissent commencer. Il s’agit d’une action explicite qui crée les bons de préparation et rend la commande visible aux opérateurs de l’entrepôt. | ||
|
Pourquoi c’est important
Cette activité lance le processus d’exécution physique. L’analyse du délai entre ce point et « Goods Shipped » révèle l’efficacité des opérations en entrepôt et les éventuels goulots d’étranglement lors du prélèvement.
Où les obtenir
Il s’agit d’un événement explicite enregistré dans le module Oracle Shipping Execution. Il peut être identifié lorsque le statut des détails de livraison dans WSH_DELIVERY_DETAILS passe à « Released to Warehouse » ou « Transactable ».
Collecte
Horodatage auquel WSH_DELIVERY_DETAILS.RELEASED_STATUS passe à « S » (Submitted).
Type d’événement
explicit
|
|||
Guides d’extraction
Prêt à commencer ?
Avec ce modèle, vous disposez de tout le nécessaire pour commencer à optimiser votre processus Order to Cash - Sales Order Processing. Commencez dès aujourd’hui à transformer votre processus et obtenez des gains d’efficacité significatifs.
Transformez dès maintenant le traitement des commandes clients Order to Cash !
Localisez les inefficacités et réduisez de 30 % le délai du cycle Order to Cash.
Aucune carte bancaire requise. Essai gratuit de 14 jours.