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
- Conseils pratiques pour l’extraction des données
Order to Cash, attributs du traitement des commandes clients
| Nom | Description | ||
|---|---|---|---|
| Commande client SalesOrder | Identifiant unique d’une commande client, utilisé comme 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. Il constitue le fil conducteur reliant toutes les activités associées, de la création et de la confirmation initiales au traitement, à la facturation et au paiement final. Dans le Process Mining, cet attribut est essentiel pour regrouper tous les événements associés dans un même dossier. L’analyse par commande client offre une vue complète de bout en bout, permet de calculer les durées totales du cycle, d’identifier les variantes du processus propres à chaque commande et de suivre son parcours entre les différents services et systèmes. Pourquoi c’est important Il s’agit de l’identifiant du dossier. Il relie tous les événements du processus et permet de retracer le parcours de bout en bout d’une même commande client. Où les obtenir Cet identifiant se trouve généralement dans la table d’en-tête des commandes clients d’Oracle Fusion, par exemple DOO_HEADERS_ALL. Consultez la documentation Oracle Fusion Financials. Exemples SO-100567SO-100568SO-100569 | |||
| Heure de l’événement EventTime | Horodatage indiquant le moment où une activité ou un événement précis s’est produit pour une commande client. | ||
| Description Cet attribut fournit la date et l’heure de chaque activité du processus et établit la séquence chronologique des événements. Il constitue la base temporelle de l’analyse du processus en enregistrant précisément le moment où chaque étape s’est produite. Dans le Process Mining, l’EventTime est essentiel pour calculer les durées de cycle, les délais entre les activités et les délais globaux des dossiers. Il permet d’analyser les performances, de détecter les goulots d’étranglement liés aux temps d’attente et de contrôler le respect des accords de niveau de service (SLA) en matière de délais. Tous les KPI et Dashboards fondés sur le temps dépendent de l’exactitude de cet attribut. Pourquoi c’est important Cet horodatage est essentiel pour classer les événements par ordre chronologique et calculer toutes les métriques temporelles, telles que les durées de cycle et les délais. Où les obtenir Il s’agit d’un attribut dérivé, alimenté par différents champs d’horodatage issus de plusieurs tables Oracle Fusion, tels que la date de création de la commande, la date d’expédition, la date de facturation et la date de paiement. Exemples 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Nom de l’activité ActivityName | Nom de l’événement métier ou de la tâche spécifique survenu dans le processus de commande client. | ||
| Description Cet attribut décrit l’étape exécutée à un moment précis pour une commande client, par exemple « Sales Order Created », « Goods Shipped » ou « Payment Received ». La séquence de ces activités constitue le flux du processus pour chaque dossier. L’analyse de l’ActivityName est fondamentale dans le Process Mining. Elle permet de visualiser la cartographie du processus, de découvrir les différentes variantes et d’identifier les goulots d’étranglement où les dossiers s’accumulent. Elle sert de base au calcul des délais de transition entre les étapes et à la compréhension de la séquence opérationnelle du processus Order to Cash. Pourquoi c’est important Cet attribut définit les étapes de la cartographie du processus et permet de visualiser et d’analyser son flux. Où les obtenir Il s’agit d’un attribut dérivé, construit en associant les statuts de transaction ou les types d’événements issus de différentes tables Oracle Fusion, par exemple le statut de la commande, de l’expédition ou de la facture, à une liste normalisée de noms d’activités. Exemples Commande client crééeMarchandises expédiéesFacture crééePaiement reçu | |||
| Canal de vente SalesChannel | Canal par lequel la commande client a été reçue. | ||
| Description Cet attribut catégorise l’origine de la commande client, par exemple « Web », « Direct Sales », « Partner » ou « EDI ». Il fournit un contexte sur la manière dont la commande est entrée dans l’organisation. La segmentation du processus par canal de vente est essentielle au Dashboard « Sales Channel Performance Overview ». Elle permet de comparer l’efficacité, les durées de cycle et les taux d’erreur des différents canaux afin d’identifier ceux qui sont les plus performants et ceux qui nécessitent des améliorations ou une automatisation accrue. Pourquoi c’est important Permet d’analyser les performances par canal et d’identifier les canaux les plus et les moins efficaces pour le traitement des commandes. Où les obtenir Cette information peut être stockée dans un champ dédié de l’en-tête de la commande client. Consultez la documentation Oracle Fusion Financials. Exemples Ventes directesPortail webEDIRevendeur | |||
| Date d’échéance du paiement PaymentDueDate | Date à laquelle le client doit avoir effectué le paiement de la facture. | ||
| Description La date d’échéance du paiement est calculée à partir de la date de facture et des conditions de paiement convenues avec le client. Elle fixe la limite à respecter pour recouvrer le paiement dans les délais. Cet attribut est essentiel au KPI « On-Time Payment Collection Rate ». En comparant la PaymentDueDate à la date réelle de réception du paiement, le système peut déterminer si le paiement a été effectué à temps ou en retard, suivre les performances des comptes clients et gérer les flux de trésorerie. Pourquoi c’est important Sert de date limite pour calculer les taux de paiement dans les délais, un indicateur important de l’efficacité des flux de trésorerie. Où les obtenir Se trouve dans les tables des comptes clients ou des factures d’Oracle Fusion, telles que AR_PAYMENT_SCHEDULES_ALL. Exemples 2023-06-192023-07-012023-06-25 | |||
| Date de livraison demandée RequestedDeliveryDate | Date de livraison de la commande demandée par le client. | ||
| Description Cet attribut enregistre la date à laquelle le client souhaite recevoir les marchandises. Il constitue une référence essentielle pour mesurer les performances de la partie traitement du processus Order to Cash. Cette date est indispensable au calcul du KPI « On-Time Delivery Rate » et alimente le Dashboard « Delivery Service Level Agreement (SLA) ». En comparant cette date à l’ActualDeliveryDate, l’organisation peut mesurer sa capacité à répondre aux attentes des clients et identifier les causes profondes des retards de livraison. Pourquoi c’est important Sert de référence pour mesurer le respect des délais de livraison et des accords de niveau de service (SLA) avec les clients. Où les obtenir Se trouve généralement dans les tables de lignes de commande d’Oracle Fusion. Consultez la documentation Oracle Fusion Financials. Exemples 2023-05-202023-06-012023-05-25 | |||
| Date de livraison réelle ActualDeliveryDate | Date à laquelle les marchandises ont effectivement été livrées au client. | ||
| Description Cet attribut enregistre la date finale de livraison, qui marque l’achèvement de la partie traitement du processus. Il s’agit du résultat réel comparé aux dates planifiées ou demandées. Cette date est comparée à la RequestedDeliveryDate pour calculer le respect des délais de livraison. Elle constitue une donnée essentielle pour le KPI « On-Time Delivery Rate » et le Dashboard « Delivery SLA », qui fournissent une mesure claire de l’efficacité de la logistique et de la chaîne logistique. Pourquoi c’est important Il s’agit de la date réelle utilisée pour calculer les taux de livraison dans les délais et évaluer les performances du traitement par rapport aux demandes des clients. Où les obtenir Provient des tables de transactions d’expédition et de livraison d’Oracle Fusion. Consultez la documentation Oracle Fusion Financials. Exemples 2023-05-202023-06-032023-05-25 | |||
| Est automatisé IsAutomated | Indicateur précisant si une activité a été exécutée automatiquement par le système ou manuellement par un utilisateur. | ||
| Description Cet attribut booléen distingue les événements pilotés par le système, par exemple une vérification de crédit automatisée ou une facture générée par le système, des actions manuelles des utilisateurs. Il est généralement dérivé du nom d’utilisateur associé à une activité, un identifiant système générique indiquant une automatisation. L’analyse de cet attribut aide à mesurer le niveau d’automatisation du processus et constitue une donnée directe du KPI « Manual Reworked Orders Percentage ». Elle peut mettre en évidence les possibilités d’automatisation en indiquant quelles étapes manuelles prennent le plus de temps ou génèrent le plus d’erreurs. Pourquoi c’est important Aide à quantifier le niveau d’automatisation du processus et à identifier les possibilités de réduire les interventions manuelles coûteuses. Où les obtenir Il s’agit d’un champ dérivé, souvent fondé sur une règle appliquée à l’attribut UserName. Par exemple, si l’utilisateur est « SYSTEM » ou « BATCH », cet indicateur est défini sur true. Exemples truefalse | |||
| Montant total de la commande client SalesOrderTotalAmount | Valeur monétaire totale de la commande client. | ||
| Description Cet attribut représente le montant total facturé au client pour l’ensemble de la commande. Il comprend la somme de toutes les lignes, les taxes et les autres frais, avant application des remises. Dans l’analyse des processus, cet attribut est essentiel au Process Mining fondé sur la valeur. Il permet de segmenter les commandes selon leur montant, par exemple entre commandes de valeur élevée et commandes de faible valeur, afin de déterminer si elles suivent des parcours différents ou présentent des durées de cycle distinctes. Il aide également à prioriser les améliorations portant sur les dossiers ayant le plus fort impact financier. Pourquoi c’est important Permet d’analyser l’impact financier, de prioriser les améliorations concernant les commandes de valeur élevée et de comprendre les facteurs de coût. Où les obtenir Se trouve généralement dans les tables d’en-tête des commandes clients d’Oracle Fusion. Consultez la documentation Oracle Fusion Financials. Exemples 5250.00125000.75980.50 | |||
| Nom de l’utilisateur UserName | Nom ou identifiant de l’utilisateur ayant exécuté l’activité. | ||
| Description Cet attribut identifie le collaborateur ou l’utilisateur système responsable de l’exécution d’une étape précise du processus. Il peut servir à analyser les performances individuelles, la répartition de la charge de travail et le respect des procédures standard. L’analyse par utilisateur aide à identifier les besoins de formation, à reconnaître les personnes ou équipes les plus performantes et à examiner les écarts imputables à certains utilisateurs. Elle est également utile à des fins de conformité et d’audit, car elle permet de savoir qui a effectué chaque action. Pourquoi c’est important Permet d’analyser les performances par utilisateur, la répartition de la charge de travail et les schémas de reprise manuelle associés à certaines personnes. Où les obtenir Provient généralement de champs tels que CREATED_BY ou LAST_UPDATED_BY dans les tables de transactions Oracle Fusion, souvent associés à une table de référence des utilisateurs telle que FND_USER. Exemples john.smithjane.doesystem_batch_user | |||
| Nom du client CustomerName | Nom du client ayant passé la commande. | ||
| Description Cet attribut identifie la dénomination légale du compte client associé à la commande. Il constitue une dimension essentielle pour segmenter et analyser le processus du point de vue du client. L’analyse par client permet de déterminer si certains clients connaissent des délais de cycle plus longs, davantage de reprises ou des écarts de processus particuliers. Ces résultats peuvent servir à améliorer le service client, à adapter les processus pour les comptes stratégiques et à examiner les problèmes qui nuisent à la satisfaction client. Pourquoi c’est important Permet une analyse centrée sur le client afin d’identifier les problèmes de processus qui touchent certains clients et d’améliorer leur satisfaction. Où les obtenir Provient des tables de référence des clients, par exemple HZ_PARTIES, et est associé à la commande client au moyen d’un identifiant client. Exemples Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Conditions de paiement PaymentTerms | Conditions convenues pour le paiement par le client. | ||
| Description Cet attribut précise les conditions dans lesquelles le client doit régler sa facture, par exemple « Net 30 » ou « Net 60 ». Ces conditions servent de base au calcul de PaymentDueDate. Dans le cadre de l’analyse, la segmentation par conditions de paiement peut aider à expliquer les variations des délais de paiement. Elle fournit le contexte nécessaire à l’interprétation du KPI « On-Time Payment Rate », car des conditions différentes entraînent naturellement des comportements de paiement différents. Ces informations peuvent guider la politique de crédit et les prévisions de trésorerie. Pourquoi c’est important Fournit le contexte nécessaire à l’analyse des comportements de paiement et aide à expliquer les variations des délais entre la facturation et le paiement. Où les obtenir Disponible au niveau de la commande client ou du compte client dans Oracle Fusion. Consultez la documentation Oracle Fusion Financials. Exemples À 30 joursÀ 60 joursPayable à réception | |||
| Dernière mise à jour des données LastUpdateDate | Horodatage indiquant la dernière actualisation des données de cet événement depuis le système source. | ||
| Description Cet attribut indique la dernière extraction ou mise à jour des données dans le jeu de données de Process Mining. Il donne de la visibilité sur l’actualité des données analysées. Cette information est essentielle pour comprendre le degré d’actualité de l’analyse du processus. Elle aide à gérer les attentes concernant la fraîcheur des données et joue un rôle important dans la définition et le suivi des calendriers d’actualisation. Pourquoi c’est important Indique la fraîcheur des données et permet aux utilisateurs de savoir dans quelle mesure leur analyse du processus est à jour. Où les obtenir Cette valeur est générée et apposée au jeu de données lors de chaque cycle d’extraction et de transformation des données. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Facture corrigée IsInvoiceCorrected | Indicateur précisant si une facture a été corrigée ou révisée après sa création initiale. | ||
| Description Cet attribut booléen prend la valeur vraie lorsqu’une facture a suivi une boucle de correction, signalée par la présence de l’activité « Invoice Corrected ». Il identifie les dossiers ayant nécessité une reprise au stade de la facturation. Il constitue une donnée essentielle pour le Dashboard « Invoice Accuracy & Rework Analysis » et le KPI « Invoice Rework Rate ». Il aide à mesurer l’ampleur des erreurs de facturation et à en analyser les causes profondes, afin de réduire le travail manuel et les retards de paiement. Pourquoi c’est important Identifie les reprises de facturation, un indicateur important de l’inefficacité des processus, des problèmes de qualité des données et des retards potentiels de paiement. Où les obtenir Il s’agit d’un champ calculé, généralement défini sur vrai pour un dossier lorsqu’une activité « Invoice Corrected » figure dans son Event Log. Exemples falsetrue | |||
| Livraison dans les délais IsOnTimeDelivery | Indicateur calculé dont la valeur est vraie si la livraison réelle a eu lieu à la date de livraison demandée ou avant celle-ci. | ||
| Description Cet attribut booléen est calculé en comparant ActualDeliveryDate et RequestedDeliveryDate. Il fournit un indicateur simple de la performance de livraison au niveau du dossier. Cet indicateur constitue la base du calcul du KPI agrégé « On-Time Delivery Rate ». Il simplifie le filtrage et l’analyse, en permettant d’isoler rapidement toutes les commandes livrées en retard afin d’analyser les causes profondes des retards. Pourquoi c’est important Mesure directement la performance d’exécution des commandes par rapport aux attentes des clients et simplifie l’analyse des commandes livrées en retard. Où les obtenir Il s’agit d’un champ calculé. La logique est la suivante : ActualDeliveryDate <= RequestedDeliveryDate. Exemples truefalse | |||
| Mode d’expédition ShippingMethod | Mode ou transporteur utilisé pour expédier les marchandises au client. | ||
| Description Cet attribut détaille le transporteur ou le niveau de service logistique utilisé pour la livraison, par exemple « Ground Freight », « Air Express » ou « Local Courier ». Cette information est essentielle au Dashboard « Shipping Method Delivery Compliance ». Elle permet de comparer le respect des délais de livraison et les coûts d’expédition selon les différents modes et transporteurs, afin d’optimiser la stratégie logistique et le choix des prestataires. Pourquoi c’est important Soutient directement l’analyse logistique en permettant de comparer les performances des différents transporteurs et modes d’expédition. Où les obtenir Disponible dans les tables d’expédition et d’exécution des commandes d’Oracle Fusion. Consultez la documentation Oracle Fusion Financials. Exemples FedEx GroundUPS Next Day AirDHL International | |||
| Nom du produit ProductName | Nom du produit ou du service vendu. | ||
| Description Cet attribut précise l’article figurant sur la ligne de commande client. Si une commande comporte plusieurs lignes, le dossier peut être analysé au niveau de la ligne, ou cet attribut peut être agrégé au niveau de l’en-tête. L’analyse par produit permet de déterminer si certains produits sont associés à des parcours de processus plus complexes ou plus problématiques, par exemple des retards de livraison fréquents ou des problèmes de paiement. Ces résultats peuvent orienter les stratégies de gestion des produits et de la chaîne logistique. Pourquoi c’est important Permet d’analyser les performances du processus pour différents produits et de repérer les articles dont le traitement ou la facturation suivent des parcours complexes. Où les obtenir Provient des tables de lignes de commande client et est associé à une table de référence des produits. Consultez la documentation Oracle Fusion Financials. Exemples Standard Widget X1Pack de services premiumComponent Y2-B | |||
| Numéro de facture InvoiceNumber | Identifiant unique de la facture client. | ||
| Description Cet attribut correspond au numéro unique attribué à la facture générée à partir de la commande client. Il relie les activités de vente et d’exécution des commandes à la phase de règlement financier du processus. Bien que la commande client soit l’identifiant de dossier principal, le numéro de facture est essentiel pour analyser les sous-processus de facturation et de paiement. Il permet notamment de suivre les corrections de factures, les litiges et le statut des paiements, et alimente des Dashboards tels que « Invoice Accuracy & Rework Analysis ». Pourquoi c’est important Établit un lien essentiel avec le processus de gestion des créances clients et permet d’analyser les reprises de facturation ainsi que les cycles de paiement. Où les obtenir Disponible dans les tables de transactions des créances clients d’Oracle Fusion, notamment RA_CUSTOMER_TRX_ALL. Exemples INV-93485INV-93486INV-93487 | |||
| Paiement en retard IsLatePayment | Indicateur calculé dont la valeur est vraie si le paiement a été reçu après la date d’échéance. | ||
| Description Cet attribut booléen est calculé en comparant la date réelle de réception du paiement à PaymentDueDate. Il indique clairement si une facture a été payée dans les délais. Cet attribut sert à calculer le KPI « On-Time Payment Rate ». Il permet de segmenter facilement les paiements effectués dans les délais et les paiements en retard, afin d’analyser les caractéristiques des clients payant tardivement, les causes fréquentes des retards et leur incidence financière sur le fonds de roulement. Pourquoi c’est important Mesure directement l’efficacité du recouvrement des paiements et simplifie l’analyse des paiements en souffrance. Où les obtenir Il s’agit d’un champ calculé. La logique est la suivante : PaymentReceivedDate > PaymentDueDate. Exemples falsetrue | |||
| Pays du client CustomerCountry | Pays dans lequel se trouve le client. | ||
| Description Cet attribut indique le pays associé à l’adresse d’expédition ou de facturation du client. Il constitue une dimension essentielle pour l’analyse géographique. La segmentation du processus par pays peut révéler des différences régionales en matière de performance, de délais de traitement ou de comportement de paiement. Elle permet de mieux comprendre l’incidence des réglementations locales, des difficultés logistiques et des conditions de marché sur le processus Order to Cash. Pourquoi c’est important Permet d’analyser les données géographiques afin d’identifier les variations régionales en matière d’efficacité des processus, de conformité et de comportement des clients. Où les obtenir Provient des tables de données de référence client (HZ_LOCATIONS, HZ_PARTY_SITES) associées à la commande client. Exemples USAAllemagneJapon | |||
| Système source SourceSystemIdentifier | Identifie le système source depuis lequel les données d’événements ont été extraites. | ||
| Description Cet attribut précise l’origine des données, ce qui est particulièrement utile dans les environnements où plusieurs systèmes interviennent dans le processus Order to Cash. Par exemple, les données de commande peuvent provenir d’Oracle Fusion, tandis que les données d’expédition peuvent être issues d’un système logistique tiers. Dans l’analyse, il aide à comprendre la traçabilité des données et peut servir à filtrer la vue du processus afin d’afficher les événements provenant de systèmes précis. Il est essentiel pour valider les données et identifier la fragmentation du processus entre différents environnements informatiques. Pourquoi c’est important Fournit un contexte sur l’origine des données, essentiel à leur gouvernance et au dépannage dans les environnements multisystèmes. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données afin d’indiquer l’origine du jeu de données. Exemples Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Type de commande OrderType | Classification de la commande client, par exemple « Standard Order » ou « Return Order ». | ||
| Description Le type de commande sert à catégoriser les commandes clients selon leur finalité métier. Les types courants comprennent les ventes standard, les commandes de service, les autorisations de retour de marchandises (RMA) et les commandes internes. L’analyse du processus par type de commande est importante, car chaque type suit souvent un flux de processus et des objectifs de performance distincts. Cette segmentation permet de distinguer les variations de processus intentionnelles et attendues des véritables écarts. Pourquoi c’est important Permet de segmenter les différents flux de processus légitimes, par exemple les commandes standard et les retours, afin de garantir une analyse juste et précise. Où les obtenir Généralement disponible dans un champ de la table d’en-tête des commandes clients d’Oracle Fusion. Consultez la documentation Oracle Fusion Financials. Exemples Commande client standardAutorisation de retourCommande de service | |||
| Unité opérationnelle BusinessUnitName | Nom de l’unité opérationnelle interne responsable de la commande client. | ||
| Description Cet attribut représente la division ou l’unité opérationnelle précise de l’entreprise qui est responsable de la transaction. Il permet de comparer les performances entre les différentes composantes de l’organisation. La segmentation du processus par unité opérationnelle aide à repérer les écarts d’efficacité, de coût et de conformité au sein de l’entreprise. Cette analyse peut révéler les bonnes pratiques des unités les plus performantes afin de les partager, ou mettre en évidence les unités moins performantes qui nécessitent des améliorations ciblées. Pourquoi c’est important Permet de comparer les performances et d’analyser la cohérence des processus entre les différentes unités de l’organisation. Où les obtenir Est généralement disponible dans l’en-tête de la commande client et associé à la structure organisationnelle définie dans Oracle Fusion. Exemples BU-North AmericaBU-EMEAServices globaux | |||
Order to Cash, activités de traitement des commandes clients
| Activité | Description | ||
|---|---|---|---|
| Commande client créée | Cette activité marque le début du processus de commande client. Elle correspond au moment où une nouvelle commande est saisie dans Oracle Fusion. Cet événement est généralement enregistré explicitement lorsqu’un utilisateur enregistre une nouvelle commande dans le module Order Management. | ||
| Pourquoi c’est important En tant que point de départ du processus, cette activité est essentielle pour mesurer la durée globale du cycle Order to Cash et analyser le volume des commandes reçues. Où les obtenir Enregistré explicitement lors de la création d’une commande client dans Order Management Cloud. Recherchez les horodatages de création dans la table DOO_HEADERS_ALL. Collecte Capturé à partir de l’horodatage de création de l’en-tête de la commande client. Type d’événement explicit | |||
| Commande clôturée | Dernière activité du processus, elle indique que toutes les lignes de la commande client ont été traitées, facturées et clôturées. Le statut de l’en-tête de commande est mis à jour à « Closed ». | ||
| Pourquoi c’est important Cette activité marque la fin réussie du cycle de vie de la commande client. Elle est essentielle pour calculer les durées de bout en bout du processus et identifier les commandes fantômes qui ne sont jamais clôturées. Où les obtenir Déduit du passage du statut de l’en-tête de la commande client à « Closed » dans la table DOO_HEADERS_ALL. L’horodatage de ce changement de statut final sert d’heure de l’événement. Collecte Dérivé de l’horodatage du passage du statut de l’en-tête de la commande client à « Closed ». Type d’événement inferred | |||
| Commande confirmée | Cette étape importante indique que la commande client a passé toutes les vérifications initiales, y compris l’approbation du crédit, et qu’elle est désormais engagée pour traitement. Elle est généralement déduite lorsque le statut de la commande passe à un état tel que « Awaiting Shipping » ou « Scheduled ». | ||
| Pourquoi c’est important Cette activité constitue une étape essentielle pour calculer le « Average Order Confirmation Time » et marque le transfert entre la saisie de la commande et le processus de traitement. Où les obtenir Déduit du changement du statut de l’en-tête ou de la ligne de commande client vers une valeur indiquant que la commande est prête à être traitée, par exemple « Awaiting Shipping ». Vérifiez les colonnes de statut dans DOO_HEADERS_ALL ou DOO_FULFILL_LINES_ALL. Collecte Dérivé de l’horodatage du passage du statut de la commande à un état confirmé ou planifié. Type d’événement inferred | |||
| Facture créée | Cette activité correspond à la création de la facture client dans le module Accounts Receivable, généralement déclenchée par l’événement de confirmation d’expédition. Un enregistrement de facture est généré avec un numéro unique et une date de création. | ||
| Pourquoi c’est important Elle marque le début officiel du cycle de recouvrement. Elle sert de base pour mesurer le « Invoice to Payment Time » et l’efficacité globale des flux de trésorerie. Où les obtenir Il s’agit d’un événement explicite dans Oracle Accounts Receivable (AR). Un enregistrement de facture est créé dans la table RA_CUSTOMER_TRX_ALL avec une date de transaction. Collecte Capturé à partir de la date de création de la transaction de facture dans le module AR. Type d’événement explicit | |||
| Marchandises expédiées | Cette activité marque le moment où les marchandises quittent l’entrepôt et sont acheminées vers le client. Elle est enregistrée lorsqu’une transaction de confirmation d’expédition est traitée dans Oracle Shipping. | ||
| Pourquoi c’est important Il s’agit d’une étape essentielle qui indique la fin de la partie traitement de la commande et déclenche la facturation. Elle est indispensable pour mesurer le respect des délais d’expédition et les délais de livraison. Où les obtenir Il s’agit d’un événement explicite enregistré dans Oracle Shipping Execution. La transaction de confirmation d’expédition crée un enregistrement dans des tables d’expédition telles que WSH_DELIVERY_DETAILS, avec une date d’expédition. Collecte Capturé à partir de l’horodatage « actual ship date » de l’enregistrement détaillé de livraison associé à la ligne de commande. Type d’événement explicit | |||
| Paiement reçu | Cette activité indique que le paiement du client a été reçu et imputé à la facture dans Accounts Receivable. Elle est enregistrée lorsqu’une imputation d’encaissement est comptabilisée. | ||
| Pourquoi c’est important Il s’agit d’une étape essentielle pour mesurer la « Overall Order to Cash Cycle Time » et le « On-Time Payment Rate ». Elle représente la conversion de la vente en encaissement. Où les obtenir Il s’agit d’un événement explicite dans Oracle Accounts Receivable. Il est enregistré dans des tables d’encaissements telles que AR_RECEIVABLE_APPLICATIONS_ALL lorsqu’un encaissement est imputé à une facture. Collecte Capturé à partir de l’horodatage « apply date » de l’enregistrement d’imputation de l’encaissement dans AR. Type d’événement explicit | |||
| Blocage pour crédit appliqué | Cette activité se produit lorsqu’une commande client est automatiquement ou manuellement bloquée à la suite d’une vérification de crédit échouée ou d’un autre problème lié au crédit. Elle est généralement enregistrée par une modification du statut de blocage de la commande dans le système. | ||
| Pourquoi c’est important Le suivi des blocages pour crédit permet d’identifier les causes des retards de traitement des commandes et de mesurer l’efficacité du processus de levée de ces blocages. Où les obtenir Déduit de l’application d’un blocage à la commande client. Cette information est généralement enregistrée dans des tables liées aux blocages, telles que DOO_HOLDS_ALL, associées à la commande client. Collecte Déduit de la création d’un enregistrement dans la table des blocages de commandes avec un type de blocage « Credit ». Type d’événement inferred | |||
| Commande annulée | Cette activité correspond à l’annulation d’une commande client avant son expédition complète. Elle peut avoir différentes causes et entraîne le passage à l’état final « Cancelled ». | ||
| Pourquoi c’est important Il s’agit d’un parcours d’exception important. L’analyse des commandes annulées aide à identifier les causes profondes, telles que les ruptures de stock, les problèmes de prix ou le changement d’avis du client, afin d’améliorer les processus. Où les obtenir Déduit du passage du statut de l’en-tête ou de la ligne de commande client à l’état « Cancelled ». L’horodatage de ce changement de statut est utilisé pour enregistrer l’événement. Collecte Dérivé de l’horodatage du passage du statut de l’en-tête ou de la ligne de commande à « Cancelled ». Type d’événement inferred | |||
| Facture corrigée | Cette activité se produit lorsqu’une facture précédemment créée est modifiée, réémise ou créditée en raison d’erreurs ou de litiges avec le client. Elle est généralement enregistrée par la création d’un avoir ou d’une nouvelle version de la facture. | ||
| Pourquoi c’est important Le suivi des corrections de factures est essentiel pour le KPI « Invoice Rework Rate ». Il met en évidence les problèmes du processus de facturation susceptibles de retarder les paiements et d’augmenter les coûts administratifs. Où les obtenir Déduit de la création d’un avoir lié à la facture d’origine ou d’une version ultérieure de la même facture dans la table RA_CUSTOMER_TRX_ALL. Collecte Dérivé de l’identification des avoirs ou des factures faisant référence à une transaction de facture antérieure. Type d’événement inferred | |||
| Ligne de commande clôturée | Cette activité correspond à la clôture définitive d’une ligne de commande client. Elle indique que la ligne a été entièrement expédiée et facturée et qu’aucune autre transaction n’est attendue. Le système met à jour le statut de la ligne à « Closed ». | ||
| Pourquoi c’est important La clôture des lignes de commande indique que toutes les obligations contractuelles liées à l’article sont remplies. Son analyse aide à repérer les commandes qui restent ouvertes longtemps après leur traitement et leur paiement. Où les obtenir Déduit du passage du statut de la ligne de traitement à « Closed » dans la table DOO_FULFILL_LINES_ALL. L’horodatage de ce changement de statut marque l’événement. Collecte Dérivé de l’horodatage du passage du statut de la ligne de traitement à « Closed ». Type d’événement inferred | |||
| Marchandises livrées | Indique que le client a reçu l’expédition. Cette information provient souvent d’un transporteur externe et est réinjectée dans Oracle Fusion. Elle peut également être déduite à partir d’un délai de transport standard calculé depuis la date d’expédition. | ||
| Pourquoi c’est important Cette activité est essentielle pour calculer le KPI « On-Time Delivery Rate » et mesurer précisément le niveau de service client. Où les obtenir Il ne s’agit souvent pas d’un événement natif d’Oracle. Il peut être capturé si une intégration avec le transporteur est en place, ou calculé en ajoutant un délai de transport standard à la date « Goods Shipped ». Une analyse du système est nécessaire. Collecte Déduit des flux de données du transporteur ou calculé à partir de la date d’expédition augmentée d’un délai de transport moyen. Type d’événement inferred | |||
| Marchandises préparées | Cette activité correspond au prélèvement physique des marchandises dans l’entrepôt pour traiter la commande. Il s’agit d’une étape importante du processus logistique, généralement enregistrée dans le module de gestion d’entrepôt ou d’expédition. | ||
| Pourquoi c’est important Cette activité offre une visibilité sur les opérations d’entrepôt. Les retards entre la réservation du stock et le prélèvement peuvent révéler des goulots d’étranglement liés aux ressources ou au processus. Où les obtenir Capturé dans les modules Oracle Fusion Cloud SCM (Supply Chain Management). Peut être déduit du changement de statut d’une vague de prélèvement ou d’un bordereau de prélèvement associé à la ligne de commande client. Collecte Déduit de l’horodatage de fin de la transaction de prélèvement dans les modules SCM. Type d’événement inferred | |||
| Stock réservé | Cette activité correspond à l’affectation ou à la réservation du stock physique nécessaire pour traiter la ligne de commande client. Le système engage un stock précis afin de garantir sa disponibilité lorsque la commande sera prête à être préparée. | ||
| Pourquoi c’est important Son suivi permet d’analyser le KPI « Inventory Allocation Lead Time » et d’identifier les retards entre la confirmation de la commande et la réservation des marchandises. Où les obtenir Cet événement est souvent enregistré dans les modules d’inventaire ou d’exécution de la chaîne logistique. Il peut être déduit des mises à jour de statut de la ligne de traitement indiquant que le stock a été détaillé ou réservé. Collecte Déduit des changements de statut de la ligne de traitement liés à la réservation ou à la planification du stock. Type d’événement inferred | |||
| Vérification du crédit effectuée | Représente l’exécution d’un contrôle de crédit sur le compte du client afin d’évaluer sa solvabilité. Il s’agit souvent d’une étape automatisée ou manuelle du flux de travail de traitement des commandes, dont l’achèvement est généralement enregistré sous la forme d’une mise à jour de statut ou d’une tâche terminée. | ||
| Pourquoi c’est important L’analyse du temps nécessaire aux vérifications de crédit aide à repérer les goulots d’étranglement dans l’approbation des commandes. Elle est essentielle pour le KPI « Credit Check to Confirmed Time ». Où les obtenir Peut être déduit des changements de statut de la commande client, par exemple lors du passage au statut « Pending Credit Approval », ou d’un journal d’événements explicite dans la fonctionnalité de gestion du crédit. Collecte Déduit des changements de statut de la commande ou des horodatages associés aux tâches d’examen du crédit. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Accéder à Oracle BI Publisher : Connectez-vous à votre environnement Oracle Fusion avec un utilisateur disposant des privilèges BI Administrator ou BI Author. Dans le menu Navigator, accédez à Tools > Reports and Analytics. Cliquez sur le bouton « Browse Catalog » pour ouvrir le catalogue Business Intelligence.
- Créer un modèle de données : Dans le catalogue BI, accédez à un dossier approprié, par exemple Shared Folders > Custom. Cliquez sur le menu déroulant « New », puis sélectionnez « Data Model ».
- Définir le jeu de données de la requête SQL : Dans l’éditeur Data Model, cliquez sur l’icône « + » pour créer un nouveau jeu de données, puis sélectionnez « SQL Query ». Une boîte de dialogue s’affiche. Nommez le jeu de données, par exemple « OrderToCash_EventLog », sélectionnez « Oracle BI EE » comme source de données et choisissez « Standard SQL » comme type de SQL.
- Saisir la requête SQL : Copiez la requête SQL complète fournie dans la section « query » de ce document et collez-la dans la zone de texte SQL Query. La requête contient les paramètres de date de début et de fin (:p_start_date et :p_end_date), qui seront automatiquement reconnus par BI Publisher.
- Configurer les propriétés du modèle de données : Après avoir collé la requête, cliquez sur « OK ». Dans le volet de gauche de l’éditeur du modèle de données, accédez à la section « Properties ». Vérifiez que l’option « Include Parameter Tags » est cochée. Vous pouvez également définir des valeurs par défaut pour les paramètres de date, si nécessaire.
- Afficher et enregistrer le modèle de données : Cliquez sur l’onglet « Data ». Il peut vous être demandé de saisir des valeurs pour les paramètres de date. Indiquez une courte période pour effectuer un test. Cliquez sur « View » pour afficher un échantillon des données. Si les données s’affichent correctement, enregistrez le modèle de données en cliquant sur l’icône d’enregistrement et en lui attribuant un nom explicite, par exemple « OrderToCash_EventLog_DM ».
- Créer un rapport à partir du modèle de données : Une fois le modèle de données enregistré, cliquez sur le bouton « Create Report » dans l’angle supérieur droit. L’assistant de création de rapport s’ouvre.
- Configurer le rapport : Dans l’assistant, sélectionnez l’option « Use Data Model ». L’assistant vous guide dans la configuration de la mise en page. Pour un export CSV simple, vous pouvez choisir la mise en page « Table ». Faites glisser toutes les colonnes dans le tableau. Cliquez sur « Next », puis décochez « Show Grand Totals Row ». Cliquez sur « Finish » pour enregistrer le rapport. Donnez-lui un nom tel que « OrderToCash_EventLog_Report ».
- Exécuter le rapport : Ouvrez le rapport nouvellement créé. Vous devrez saisir les dates de début et de fin de l’extraction. Indiquez la période souhaitée.
- Exporter les données : Une fois le rapport exécuté, cliquez sur le menu déroulant « View » et sélectionnez une autre option d’affichage, telle que « View Report ». Recherchez ensuite le lien ou l’icône « Export » et choisissez « CSV » comme format d’exportation. Le fichier du journal d’événements sera téléchargé.
- Préparer le chargement : Ouvrez le fichier CSV téléchargé. Vérifiez que les en-têtes de colonnes correspondent aux attributs requis : SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate et IsAutomated. Le fichier est maintenant prêt à être chargé dans l’outil de Process Mining.
Configuration
- Privilèges utilisateur : Vous devez disposer d’un rôle autorisant la création de modèles de données et de rapports BI Publisher, tel que « BI Administrator » ou « BI Author ».
- Source de données : La requête est conçue pour la source de données applicative standard « Oracle BI EE », qui se connecte à la base de données transactionnelle, Fusion Apps. Aucune configuration particulière n’est généralement nécessaire.
- Paramètres de période : La requête utilise deux paramètres, :p_start_date et :p_end_date, pour filtrer les données. Il est vivement recommandé d’extraire les données par lots de taille raisonnable, par exemple sur des périodes de 3 à 6 mois, afin d’éviter les délais d’expiration et les problèmes de performance des rapports.
- Filtrage par unité opérationnelle : Pour limiter le périmètre de l’extraction, vous pouvez ajouter une clause WHERE à la CTE BaseOrders de la requête afin de filtrer une unité opérationnelle donnée, par exemple AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filtrage par type de commande : Vous pouvez également filtrer certains types de commandes clients en ajoutant une condition sur dhead.SOURCE_ORDER_TYPE_CODE dans la CTE BaseOrders.
- Performances : Pour de très grands volumes couvrant plusieurs années, cette approche fondée sur une seule requête peut être lente. Envisagez de l’exécuter en dehors des heures de pointe ou de répartir l’extraction en lots mensuels plus petits. Vérifiez que la propriété « Enable SQL Pruning » n’est pas sélectionnée dans le modèle de données, car elle peut perturber les requêtes UNION complexes.
a Exemple de requête sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED'Étapes
- Accéder à la console BICC : Connectez-vous à votre instance Oracle Fusion Applications avec un utilisateur disposant du rôle BICC_ADMINISTRATOR. Accédez à Tools, puis sélectionnez Business Intelligence Cloud Connector dans le menu.
- Créer une nouvelle offre : Dans la console BICC, cliquez sur Configure External Storage pour configurer la destination cible, qui peut être Oracle Universal Content Management (UCM) ou un compartiment OCI Object Storage. Vérifiez l’exactitude des informations de connexion et des identifiants.
- Lancer une nouvelle tâche d’extraction : Accédez à la section Manage Extract Jobs. Cliquez sur l’icône « + » pour créer une tâche. Donnez-lui un nom explicite, par exemple ProcessMind_O2C_SalesOrder_Extract.
- Sélectionner les magasins de données (PVO) : Dans la configuration de la tâche, recherchez et ajoutez les Public View Objects (PVO) nécessaires pour couvrir le cycle de vie de la commande client. Vous devez ajouter plusieurs PVO, notamment FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice et FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Configurer les colonnes de chaque PVO : Pour chaque PVO sélectionné, cliquez sur le menu Actions et choisissez Select Columns. Sélectionnez attentivement les colonnes nécessaires à la génération du journal d’événements, telles que HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate et les identifiants utilisateur. Consultez le manifeste de la requête pour obtenir la liste détaillée des colonnes requises pour chaque PVO.
- Appliquer des filtres pour les chargements incrémentiels : Pour maîtriser le volume de données, appliquez à chaque PVO un filtre fondé sur la colonne LastUpdateDate. Lors de l’exécution initiale, vous pouvez sélectionner une période étendue. Pour les exécutions planifiées suivantes, configurez ce filtre afin d’extraire uniquement les enregistrements mis à jour depuis la dernière exécution.
- Planifier la tâche d’extraction : Accédez à la section Manage Schedule. Créez une nouvelle planification pour votre tâche. Il est recommandé d’exécuter la tâche en dehors des heures de pointe, par exemple chaque nuit, afin de limiter son impact sur les performances du système.
- Soumettre et surveiller la tâche : Une fois la configuration terminée, soumettez la tâche. Vous pouvez suivre sa progression depuis l’écran Manage Extract Jobs. Une fois l’exécution terminée, les fichiers de données sont disponibles dans l’emplacement de stockage cloud configuré, au format CSV compressé.
- Transformer les données brutes en journal d’événements : Téléchargez les fichiers CSV extraits. BICC fournit des données brutes issues des tables, et non un journal d’événements formaté. Vous devez utiliser un outil externe, tel que Python, un script de base de données ou une plateforme ETL, pour traiter ces fichiers. Cette étape comprend notamment :
- La jointure des données provenant de différents fichiers, par exemple en reliant les données de facture à l’en-tête de la commande client.
- La transformation des colonnes de date en lignes d’activité distinctes. Par exemple, à partir du fichier FscmTopModelAM.DooTopAM.Header, créez une ligne Sales Order Created à partir de CreationDate et une autre ligne Order Closed à partir de ClosedDate.
- La mise en correspondance des codes d’état ou des indicateurs avec des activités précises, telles que Order Confirmed ou Order Cancelled.
- La consolidation de toutes les données transformées dans un fichier unique contenant les colonnes requises : SalesOrder, ActivityName et EventTime.
- Mettre en forme pour le chargement : Vérifiez que le fichier final transformé est un fichier CSV unique dont les colonnes correspondent aux attributs requis et recommandés. Le fichier est maintenant prêt à être chargé dans ProcessMind.
Configuration
- Sélection des PVO : La précision du journal d’événements dépend entièrement de la sélection des bons PVO. Les principaux PVO comprennent FscmTopModelAM.DooTopAM.Header, pour la création et la clôture des commandes, FscmTopModelAM.ScmTopAM.ShipmentLine, pour les événements d’expédition, et FscmTopModelAM.ArTopAM.ReceivableInvoice, pour la facturation.
- Extraction incrémentielle : Utilisez toujours le filtre LastUpdateDate pour les extractions récurrentes. Ce filtre est essentiel aux performances et évite d’extraire plusieurs fois le même jeu de données de plusieurs gigaoctets. Le chargement complet initial doit établir une référence, puis les exécutions suivantes ne doivent capturer que les modifications.
- Période : Pour le premier chargement historique, extrayez une période représentative, par exemple les 3 à 6 derniers mois de données, afin de trouver un équilibre entre exhaustivité et volume maîtrisable. Les exécutions suivantes seront incrémentielles.
- Configuration du stockage : BICC peut exporter les données vers Oracle UCM ou OCI Object Storage. OCI Object Storage est généralement recommandé pour les scénarios de traitement de gros volumes et pour faciliter l’intégration avec les outils ETL en aval.
- Planification des tâches : Planifiez les tâches d’extraction en dehors des heures ouvrées afin d’éviter toute dégradation potentielle des performances du système transactionnel Oracle Fusion Financials.
- Prérequis : Les utilisateurs qui configurent la tâche doivent disposer du rôle BICC_ADMINISTRATOR. Vous devez avoir préconfiguré les identifiants du stockage cloud et bien comprendre la logique de transformation nécessaire après l’extraction.
a Exemple de requête config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filteringPrêt à commencer ?
Utilisez ce modèle pour simplifier la collecte de vos données et commencer votre démarche de Process Mining. Commencez dès aujourd’hui à optimiser votre processus Order to Cash - Sales Order Processing.
Optimisez dès aujourd’hui le processus Order to Cash - Traitement des commandes clients
Identifiez les goulots d’étranglement et réduisez facilement de 30 % la durée du cycle Order to Cash.
Aucune carte bancaire requise, essai gratuit de 14 jours.