Votre modèle de données pour le traitement des commandes clients, de la commande à l’encaissement
Votre modèle de données pour le traitement des commandes clients, de la commande à l’encaissement
- Attributs recommandés à recueillir
- Activités clés à suivre
- Conseils pratiques pour l’extraction des données
Attributs du traitement des commandes clients, de la commande à l’encaissement
| Nom | Description | ||
|---|---|---|---|
| Commande client SalesOrder | Identifiant unique d’une commande client, qui constitue le cas principal du processus de la commande à l’encaissement. | ||
| Description Le numéro de commande client identifie chaque commande de manière unique tout au long de son cycle de vie. Il relie les activités associées, de la création et de la confirmation initiales à l’exécution, à la facturation et au paiement final. En Process Mining, cet attribut est essentiel pour regrouper tous les événements associés dans un même cas. L’analyse par commande client donne une vue complète du processus, permet de calculer les temps de cycle totaux, de repérer les variantes de processus propres à chaque commande et de suivre son parcours entre les différents services et systèmes. Pourquoi est-ce important ? Il s’agit de l’ID de cas. Il relie tous les événements du processus et permet de retracer le parcours complet d’une commande client. Où trouver ces données Cet identifiant se trouve généralement dans la table d’en-tête des commandes client 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 donné s’est produit pour une commande client. | ||
| Description Cet attribut indique la date et l’heure de chaque activité du processus et établit ainsi l’ordre chronologique des événements. Il constitue la référence temporelle de l’analyse du processus en enregistrant précisément le moment où chaque étape a eu lieu. En Process Mining, l’EventTime est essentiel pour calculer les temps de cycle, les durées entre les activités et les délais globaux des cas. Il permet d’analyser les performances, de repérer les goulots d’étranglement à partir des temps d’attente et de suivre le respect des accords de niveau de service (SLA) en matière de délais. La fiabilité de cet attribut conditionne tous les KPI et Dashboards fondés sur le temps. Pourquoi est-ce important ? Cet horodatage est essentiel pour ordonner les événements chronologiquement et calculer toutes les métriques temporelles, notamment les temps de cycle et les durées. Où trouver ces données Cet attribut est calculé à partir de différents champs d’horodatage dans les tables Oracle Fusion, comme 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 qui s’est produit dans le processus de commande client. | ||
| Description Cet attribut décrit l’étape exécutée à un moment donné pour une commande client, par exemple « Commande client créée », « Marchandises expédiées » ou « Paiement reçu ». La succession de ces activités constitue le flux du processus pour chaque cas. L’analyse de l’ActivityName est fondamentale en Process Mining. Elle permet de visualiser la cartographie du processus, de découvrir les différentes variantes et de repérer les goulots d’étranglement où les cas s’accumulent. Elle sert aussi à calculer les temps de transition entre les étapes et à comprendre le déroulement opérationnel du processus de la commande à l’encaissement. Pourquoi est-ce important ? Cet attribut définit les étapes de la cartographie du processus et permet de visualiser et d’analyser son déroulement. Où trouver ces données Cet attribut est calculé en associant les statuts de transaction ou les types d’événement 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é. Exemples Commande client crééeMarchandises expédiéesFacture crééePaiement reçu | |||
| Automatisé IsAutomated | Indicateur précisant si une activité a été effectuée automatiquement par le système ou manuellement par un utilisateur. | ||
| Description Cet attribut booléen distingue les événements déclenchés par le système, comme un contrôle de solvabilité automatisé ou une facture générée par le système, des actions manuelles des utilisateurs. Il est généralement calculé à partir du nom d’utilisateur associé à une activité : un identifiant système générique indique une automatisation. L’analyse de cet attribut permet de mesurer le degré d’automatisation du processus. Elle contribue directement au KPI « Pourcentage de commandes retouchées manuellement » et peut mettre en évidence les possibilités d’automatisation en repérant les étapes manuelles les plus longues ou les plus sujettes aux erreurs. Pourquoi est-ce important ? Aide à mesurer le degré d’automatisation du processus et à repérer les possibilités de réduire les interventions manuelles coûteuses. Où trouver ces données Ce champ est calculé, souvent à partir d’une règle appliquée à l’attribut UserName. Par exemple, si l’utilisateur est « SYSTEM » ou « BATCH », cet indicateur prend la valeur true. Exemples truefalse | |||
| Canal de vente SalesChannel | Canal par lequel la commande client a été reçue. | ||
| Description Cet attribut indique l’origine de la commande client, par exemple « Web », « Vente directe », « Partenaire » ou « EDI ». Il précise comment la commande est entrée dans l’organisation. La segmentation du processus par canal de vente est essentielle au Dashboard « Vue d’ensemble des performances des canaux de vente ». Elle permet de comparer l’efficacité, les temps de cycle et les taux d’erreur des différents canaux, afin de repérer ceux qui fonctionnent le mieux et ceux qui nécessitent des améliorations ou une automatisation accrue. Pourquoi est-ce important ? Permet d’analyser les performances par canal et de repérer les canaux les plus et les moins efficaces pour le traitement des commandes. Où trouver ces données Cette information peut être stockée dans un champ dédié de l’en-tête de commande client. Consultez la documentation Oracle Fusion Financials. Exemples Vente directePortail webEDIRevendeur | |||
| Date d’échéance du paiement PaymentDueDate | Date limite à laquelle le client doit régler 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 date limite de recouvrement du paiement. Cet attribut est essentiel au KPI « Taux de recouvrement des paiements dans les délais ». En comparant PaymentDueDate à la date réelle de réception du paiement, le système détermine si le règlement a été effectué à temps ou en retard. Il permet ainsi de suivre les performances des comptes clients et de gérer la trésorerie. Pourquoi est-ce important ? Sert de date limite pour calculer le taux de paiements dans les délais, un indicateur important de l’efficacité de la trésorerie. Où trouver ces données Se trouve dans les tables des comptes clients ou des factures d’Oracle Fusion, par exemple 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 indique la date à laquelle le client souhaite recevoir les marchandises. Il constitue un objectif de performance important pour la partie exécution du processus de la commande à l’encaissement. Cette date est essentielle au calcul du KPI « Taux de livraisons dans les délais » et au suivi du Dashboard « Accord de niveau de service de livraison (SLA) ». En la comparant à ActualDeliveryDate, l’organisation peut mesurer sa capacité à répondre aux attentes des clients et rechercher les causes des retards de livraison. Pourquoi est-ce important ? Sert de référence pour mesurer les performances de livraison dans les délais et le respect des accords de niveau de service (SLA) avec les clients. Où trouver ces données Se trouve généralement dans les tables des lignes de commande client 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 de livraison finale, qui marque la fin de la partie exécution du processus. Il s’agit du résultat réel auquel sont comparées les dates prévues ou demandées. Cette date est comparée à RequestedDeliveryDate pour calculer les performances de livraison dans les délais. Elle est essentielle au KPI « Taux de livraisons dans les délais » et au Dashboard « SLA de livraison », qui mesurent clairement l’efficacité de la logistique et de la chaîne d’approvisionnement. Pourquoi est-ce important ? Cette date de réalisation sert à calculer le taux de livraisons dans les délais et à évaluer l’exécution des commandes au regard des demandes des clients. Où trouver ces données 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 | |||
| 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 des articles, des taxes et des autres frais, avant déduction des remises éventuelles. Dans l’analyse des processus, cet attribut est essentiel au Process Mining fondé sur la valeur. Il permet de répartir les commandes selon leur montant, par exemple entre commandes de valeur élevée et faible, afin de vérifier si elles suivent des parcours différents ou présentent des temps de cycle distincts. Il aide également à prioriser les améliorations portant sur les cas ayant le plus grand poids financier. Pourquoi est-ce important ? Permet d’évaluer l’impact financier, de prioriser les améliorations des processus concernant les commandes de valeur élevée et de comprendre les facteurs de coût. Où trouver ces données Se trouve généralement dans les tables d’en-tête des commandes client d’Oracle Fusion. Consultez la documentation Oracle Fusion Financials. Exemples 5250.00125000.75980.50 | |||
| Nom d’utilisateur UserName | Nom ou identifiant de l’utilisateur qui a effectué l’activité. | ||
| Description Cet attribut identifie l’employé ou l’utilisateur système responsable de l’exécution d’une étape précise du processus. Il permet d’analyser les performances par utilisateur, la répartition de la charge de travail et le respect des procédures standard. L’analyse par utilisateur aide à repérer les besoins de formation, à reconnaître les personnes ou les équipes les plus performantes et à examiner les écarts liés à certains utilisateurs. Elle est également utile à des fins de conformité et d’audit, car elle permet de savoir qui a effectué chaque action. Pourquoi est-ce important ? Permet d’analyser les performances par utilisateur, la répartition de la charge de travail et les reprises manuelles associées à certaines personnes. Où trouver ces données Provient généralement de champs tels que CREATED_BY ou LAST_UPDATED_BY dans les tables de transaction Oracle Fusion, souvent reliés à une table des utilisateurs comme FND_USER. Exemples john.smithjane.doesystem_batch_user | |||
| Nom du client CustomerName | Nom du client qui a passé la commande. | ||
| Description Cet attribut indique la raison sociale du compte client associé à la commande. Il constitue une dimension importante pour segmenter et analyser le processus du point de vue du client. L’analyse par client permet de repérer ceux qui connaissent des temps 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 aux comptes stratégiques et à examiner les problèmes qui nuisent à la satisfaction des clients. Pourquoi est-ce important ? Permet d’analyser le processus du point de vue du client, de repérer les problèmes qui touchent certains clients et d’améliorer leur satisfaction. Où trouver ces données Provient des tables de données de référence des clients (par exemple, HZ_PARTIES) et est relié à la commande client par un identifiant client. Exemples Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Conditions de paiement PaymentTerms | Conditions de paiement convenues avec le client. | ||
| Description Cet attribut précise les conditions dans lesquelles le client doit régler sa facture, par exemple « Net à 30 jours » ou « Net à 60 jours ». Ces conditions servent de base au calcul de PaymentDueDate. La segmentation par conditions de paiement peut aider à expliquer les variations des temps de cycle de paiement. Elle apporte un contexte au KPI « Taux de paiements dans les délais », car les différentes conditions entraînent naturellement des comportements de paiement différents. Ces informations peuvent éclairer la politique de crédit et les prévisions de trésorerie. Pourquoi est-ce important ? Apporte un contexte important à l’analyse des comportements de paiement et aide à expliquer les variations du temps de cycle entre la facturation et le paiement. Où trouver ces données Disponible au niveau de la commande client ou du compte client dans Oracle Fusion. Consultez la documentation Oracle Fusion Financials. Exemples Net à 30 joursNet à 60 joursÀ 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 date de la dernière extraction ou mise à jour des données dans le jeu de données de Process Mining. Il permet de connaître leur niveau d’actualité. Cette information aide les utilisateurs à évaluer la fraîcheur de l’analyse du processus. Elle permet de savoir dans quelle mesure les données sont à jour et contribue à définir et à surveiller les calendriers d’actualisation. Pourquoi est-ce important ? Indique si les données sont à jour, afin que les utilisateurs sachent à quel point l’analyse du processus est récente. Où trouver ces données Cette valeur est générée et ajoutée au jeu de données à chaque cycle d’extraction et de transformation. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Facture corrigée IsInvoiceCorrected | Indique 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 true si une facture a fait l’objet d’une boucle de correction, signalée par la présence de l’activité « Facture corrigée ». Il repère les dossiers ayant nécessité des reprises au stade de la facturation. Cet attribut est utilisé dans le Dashboard « Analyse de la précision des factures et des reprises » et pour le KPI « Taux de reprise des factures ». Il permet de mesurer l’ampleur des erreurs de facturation et d’en rechercher les causes afin de réduire le travail manuel et les retards de paiement. Pourquoi est-ce important ? Repère les reprises de facturation, un indicateur important d’inefficacité des processus, de problèmes de qualité des données et de retards de paiement potentiels. Où trouver ces données Il s’agit d’un champ calculé, généralement défini sur true pour un dossier si l’activité « Facture corrigée » figure dans son journal d’événements. Exemples falsetrue | |||
| Livraison dans les délais IsOnTimeDelivery | Indicateur calculé qui prend la valeur true si la livraison réelle a eu lieu à la date demandée ou avant. | ||
| Description Cet attribut booléen est calculé en comparant ActualDeliveryDate à RequestedDeliveryDate. Il indique simplement, pour chaque cas, si la livraison a été effectuée dans les délais. Cet indicateur sert de base au calcul du KPI global « Taux de livraisons dans les délais ». Il facilite le filtrage et l’analyse, en permettant d’isoler rapidement les commandes en retard et d’en rechercher les causes. Pourquoi est-ce important ? Mesure directement les performances d’exécution au regard des attentes des clients et facilite l’analyse des commandes en retard. Où trouver ces données Ce champ est calculé selon la règle suivante : ActualDeliveryDate <= RequestedDeliveryDate. Exemples truefalse | |||
| Mode d’expédition ShippingMethod | Mode ou transporteur utilisé pour expédier les marchandises au client. | ||
| Description Cet attribut précise le transporteur ou le niveau de service logistique utilisé pour la livraison, par exemple « Fret terrestre », « Express aérien » ou « Coursier local ». Cette information est essentielle au Dashboard « Respect des délais selon le mode d’expédition ». Elle permet de comparer les livraisons dans les délais et les coûts d’expédition selon les modes et les transporteurs, afin d’optimiser la stratégie logistique et le choix des prestataires. Pourquoi est-ce important ? Permet d’analyser la logistique en comparant directement les performances des différents transporteurs et modes d’expédition. Où trouver ces données Disponible dans les tables d’expédition et d’exécution 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 indique l’article figurant sur la ligne de commande client. Si une commande comporte plusieurs lignes, le cas peut être analysé au niveau de chaque article 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 processus plus complexes ou problématiques, par exemple à des retards de livraison fréquents ou à des problèmes de paiement. Ces résultats peuvent éclairer les décisions relatives à la gestion des produits et à la chaîne d’approvisionnement. Pourquoi est-ce important ? Permet d’analyser les performances du processus pour différents produits et de repérer ceux dont l’exécution ou la facturation suivent des parcours complexes. Où trouver ces données Provient des tables des lignes de commande client et est associé à une table de référence des produits. Consultez la documentation Oracle Fusion Financials. Exemples Widget standard X1Forfait de services premiumComposant 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 à la partie financière du processus. La commande client étant l’ID de cas principal, le numéro de facture est essentiel à l’analyse des sous-processus de facturation et de paiement. Il permet de suivre les corrections de factures, les litiges et le statut des paiements, et contribue à alimenter des Dashboards tels que « Exactitude des factures et analyse des retouches ». Pourquoi est-ce important ? Établit un lien important avec le processus des comptes clients et permet d’analyser les retouches de factures et les cycles de paiement. Où trouver ces données Disponible dans les tables de transactions des comptes clients d’Oracle Fusion, par exemple RA_CUSTOMER_TRX_ALL. Exemples INV-93485INV-93486INV-93487 | |||
| Paiement en retard IsLatePayment | Indicateur calculé qui prend la valeur true si le paiement a été reçu après sa 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 au calcul du KPI « Taux de paiements dans les délais ». Il permet de distinguer facilement les paiements effectués à temps des paiements en retard, afin d’analyser les caractéristiques des clients payant en retard, les causes fréquentes des retards et leur incidence financière sur le fonds de roulement. Pourquoi est-ce important ? Mesure directement l’efficacité du recouvrement des paiements et facilite l’analyse des retards de paiement. Où trouver ces données Il s’agit d’un champ calculé. La logique est la suivante : PaymentReceivedDate > PaymentDueDate. Exemples falsetrue | |||
| Pays du client CustomerCountry | Pays où se trouve le client. | ||
| Description Cet attribut indique le pays associé à l’adresse de livraison ou de facturation du client. Il constitue une dimension importante pour l’analyse géographique. La segmentation du processus par pays peut révéler des différences régionales en matière de performances, de temps de cycle ou de comportement de paiement. Elle aide à comprendre l’incidence des réglementations locales, des difficultés logistiques et des conditions du marché sur le processus de la commande à l’encaissement. Pourquoi est-ce important ? Permet une analyse géographique pour repérer les différences régionales en matière d’efficacité des processus, de conformité et de comportement des clients. Où trouver ces données Provient des tables de données de référence des clients (HZ_LOCATIONS, HZ_PARTY_SITES) reliées à la commande client. Exemples USAAllemagneJapon | |||
| Système source SourceSystemIdentifier | Indique le système source dont les données d’événement ont été extraites. | ||
| Description Cet attribut précise l’origine des données, ce qui est particulièrement utile lorsque plusieurs systèmes interviennent dans le processus de la commande à l’encaissement. Par exemple, les données de commande peuvent provenir d’Oracle Fusion, tandis que les données d’expédition sont issues d’un système logistique tiers. L’analyse permet de comprendre la traçabilité des données et de filtrer la vue du processus pour afficher les événements provenant de systèmes précis. Cet attribut est essentiel pour valider les données et repérer la fragmentation du processus entre différents environnements informatiques. Pourquoi est-ce important ? Précise l’origine des données, un élément essentiel à leur gouvernance et au diagnostic des problèmes dans les environnements faisant intervenir plusieurs systèmes. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données pour 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 « Commande standard » ou « Commande de retour ». | ||
| Description Le type de commande sert à classer les commandes client selon leur objectif 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 les différents types suivent souvent des parcours et des objectifs de performance distincts. Cette segmentation permet de reconnaître les variations de processus prévues et légitimes, plutôt que de les interpréter à tort comme des écarts. Pourquoi est-ce important ? Permet de distinguer les différents parcours de processus légitimes, par exemple les commandes standard et les retours, pour garantir une analyse équitable et précise. Où trouver ces données Généralement disponible dans un champ de la table d’en-tête des commandes client 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 désigne la division ou l’unité opérationnelle de l’entreprise à laquelle la transaction est rattachée. Il permet de comparer les performances entre les différentes entités 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. Elle peut mettre en évidence les pratiques efficaces à partager ou les unités dont les performances nécessitent des améliorations ciblées. Pourquoi est-ce important ? Permet de comparer les performances et la cohérence des processus entre les différentes unités de l’organisation. Où trouver ces données Généralement disponible dans l’en-tête de commande client et relié à la structure organisationnelle définie dans Oracle Fusion. Exemples Unité opérationnelle - Amérique du NordUnité opérationnelle - EMEAServices mondiaux | |||
Activités du traitement des commandes clients, de la commande à l’encaissement
| Activité | Description | ||
|---|---|---|---|
| Commande client créée | Cette activité marque le début du processus de commande client : une nouvelle commande est saisie dans Oracle Fusion. L’événement est généralement enregistré explicitement lorsqu’un utilisateur enregistre une nouvelle commande dans le module Order Management. | ||
| Pourquoi est-ce important ? Première activité du processus, elle est indispensable pour mesurer le temps de cycle global du processus Order to Cash et analyser le volume de commandes reçues. Où trouver ces données L’événement est 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. Données à recueillir À 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 : toutes les lignes de la commande client ont été exécutées, facturées et clôturées. Le statut de l’en-tête de commande passe à « Closed ». | ||
| Pourquoi est-ce important ? Cette activité marque la fin du cycle de vie de la commande client. Elle est indispensable au calcul des durées de bout en bout et au repérage des commandes fantômes qui ne sont jamais clôturées. Où trouver ces données Déduit du passage du statut de l’en-tête de commande client à « Closed » dans la table DOO_HEADERS_ALL. L’horodatage de ce changement de statut final sert d’heure d’événement. Données à recueillir Calculé à partir de l’horodatage du passage de l’en-tête de commande client au statut « Closed ». Type d’événement inferred | |||
| Commande confirmée | Ce jalon indique que la commande client a passé toutes les vérifications initiales, y compris l’approbation du crédit, et qu’elle peut désormais être préparée. Il est généralement déduit du passage de la commande à un statut tel que « En attente d’expédition » ou « Planifiée ». | ||
| Pourquoi est-ce important ? Ce jalon est essentiel pour calculer le « Délai moyen de confirmation des commandes ». Il marque le passage de la saisie de la commande à sa préparation. Où trouver ces données Déduit du changement de statut de l’en-tête ou de la ligne de commande vers une valeur indiquant que la commande est prête à être préparée, par exemple « En attente d’expédition ». Vérifiez les colonnes de statut dans DOO_HEADERS_ALL ou DOO_FULFILL_LINES_ALL. Données à recueillir Calculé à partir de l’horodatage du changement de statut de la commande vers 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 la confirmation d’expédition. Un enregistrement de facture est créé avec un numéro unique et une date de création. | ||
| Pourquoi est-ce important ? Elle marque le début officiel du cycle de recouvrement des paiements. Elle sert de référence pour mesurer le « Délai entre la facture et le paiement » et l’efficacité globale de la trésorerie. Où trouver ces données 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. Données à recueillir À 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 départ des marchandises de l’entrepôt et leur acheminement vers le client. Elle est enregistrée lorsqu’une transaction de confirmation d’expédition est traitée dans Oracle Shipping. | ||
| Pourquoi est-ce important ? Ce jalon marque la fin de la phase de préparation de la commande et déclenche la facturation. Il est essentiel pour mesurer le respect des délais d’expédition et de livraison. Où trouver ces données 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. Données à recueillir À partir de l’horodatage de la « date réelle d’expédition » dans l’enregistrement des détails 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 le module Comptes clients. Elle est enregistrée lors de la comptabilisation de l’imputation d’un encaissement. | ||
| Pourquoi est-ce important ? Cette étape est essentielle pour mesurer le « Temps de cycle global de la commande à l’encaissement » et le « Taux de paiements dans les délais ». Elle marque la conversion de la vente en encaissement. Où trouver ces données 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 paiement est imputé à une facture. Données à recueillir Récupéré à partir de l’horodatage du champ « apply date » de l’enregistrement d’imputation de l’encaissement dans AR. Type d’événement explicit | |||
| Blocage de crédit appliqué | Cette activité a lieu lorsqu’une commande client est bloquée automatiquement ou manuellement à la suite d’une vérification de crédit non concluante ou d’un autre problème lié au crédit. Elle est généralement enregistrée par un changement du statut de blocage de la commande dans le système. | ||
| Pourquoi est-ce important ? Le suivi des blocages de crédit permet d’identifier les causes des retards de traitement des commandes et de mesurer l’efficacité du processus de levée des blocages. Où trouver ces données Déduit de l’application d’un blocage à la commande client. L’événement est généralement enregistré dans des tables relatives aux blocages, comme DOO_HOLDS_ALL, associées à la commande. Données à recueillir Déduit de la création d’un enregistrement dans la table des blocages de commandes avec le type de blocage « Crédit ». Type d’événement inferred | |||
| Commande annulée | Indique l’annulation d’une commande client avant l’expédition complète des marchandises. Plusieurs raisons peuvent l’expliquer ; le statut final devient alors « Cancelled ». | ||
| Pourquoi est-ce important ? Il s’agit d’un parcours d’exception important. L’analyse des commandes annulées permet d’en rechercher les causes, par exemple une rupture de stock, un problème de prix ou un changement d’avis du client, afin d’améliorer le processus. Où trouver ces données Déduit du passage de l’en-tête ou de la ligne de commande client à l’état « Cancelled ». L’horodatage de ce changement de statut sert à enregistrer l’événement. Données à recueillir Calculé à partir de l’horodatage du passage de l’en-tête ou de la ligne de commande au statut « Cancelled ». Type d’événement inferred | |||
| Facture corrigée | Se produit lorsqu’une facture déjà créée est modifiée, réémise ou créditée à la suite d’une erreur ou d’un litige client. Cette opération est généralement enregistrée par la création d’un avoir ou d’une nouvelle version de la facture. | ||
| Pourquoi est-ce important ? Le suivi des corrections de factures est essentiel pour calculer le KPI « Taux de retouches des factures ». Il met en évidence les problèmes de facturation susceptibles de retarder les paiements et d’augmenter les coûts administratifs. Où trouver ces données Déduit de la création d’un avoir lié à la facture d’origine ou d’une version ultérieure de cette même facture dans la table RA_CUSTOMER_TRX_ALL. Données à recueillir Calculé en repérant les avoirs ou les factures qui font référence à une transaction de facture antérieure. Type d’événement inferred | |||
| Ligne de commande clôturée | Indique la clôture définitive d’une ligne de commande client : les marchandises ont été expédiées et facturées, et aucune autre transaction n’est attendue. Le statut de la ligne passe alors à « Closed ». | ||
| Pourquoi est-ce important ? La clôture des lignes de commande marque l’exécution de toutes les obligations contractuelles associées à l’article. Cette analyse permet de repérer les commandes qui restent ouvertes longtemps après leur livraison et leur paiement. Où trouver ces données Déduit du passage du statut de la ligne d’exécution à « Closed » dans la table DOO_FULFILL_LINES_ALL. L’horodatage de ce changement de statut marque l’événement. Données à recueillir Calculé à partir de l’horodatage du passage de la ligne d’exécution au statut « Closed ». Type d’événement inferred | |||
| Marchandises livrées | Indique que le client a reçu l’expédition. Ces informations proviennent souvent du transporteur et sont mises à jour dans Oracle Fusion. Elles peuvent aussi être déduites à partir d’un délai de transit standard calculé depuis la date d’expédition. | ||
| Pourquoi est-ce important ? Cette activité est essentielle pour calculer le KPI « Taux de livraison à temps » et mesurer avec précision le niveau de service client. Où trouver ces données Cet événement n’est souvent pas natif dans Oracle. Il peut être enregistré si une intégration avec le transporteur est en place, ou calculé en ajoutant un délai de transit standard à la date « Marchandises expédiées ». Une analyse du système est nécessaire. Données à recueillir Déduit des données transmises par le transporteur ou calculé à partir de la date d’expédition et d’un délai de transit moyen. Type d’événement inferred | |||
| Marchandises prélevées | Cette activité correspond au prélèvement physique des marchandises dans l’entrepôt pour préparer la commande. Étape clé du processus logistique, elle est généralement enregistrée dans le module de gestion d’entrepôt ou d’expédition. | ||
| Pourquoi est-ce important ? Cette activité donne de la visibilité sur les opérations d’entrepôt. Un retard entre la réservation des stocks et le prélèvement peut signaler un goulot d’étranglement lié aux ressources ou au processus. Où trouver ces données L’événement est enregistré dans les modules Oracle Fusion Cloud SCM (Supply Chain Management). Il 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. Données à recueillir 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 de stocks physiques pour préparer une ligne de commande client. Le système réserve des articles précis afin qu’ils soient disponibles au moment du prélèvement. | ||
| Pourquoi est-ce important ? Le suivi de cette activité permet d’analyser le KPI « Délai d’affectation des stocks » et de repérer les retards entre la confirmation de la commande et la réservation des marchandises. Où trouver ces données Cet événement est souvent enregistré dans les modules de gestion des stocks ou d’exécution de la chaîne logistique. Il peut être déduit des mises à jour de statut de la ligne de préparation indiquant que les stocks ont été détaillés ou réservés. Données à recueillir Déduit des changements de statut de la ligne de préparation liés à la réservation des stocks ou à la planification. Type d’événement inferred | |||
| Vérification du crédit effectuée | Cette activité correspond à la vérification de la solvabilité du client à partir de son compte. Il s’agit souvent d’une étape automatisée ou manuelle du flux de travail de traitement des commandes. Sa réalisation est généralement enregistrée sous la forme d’une mise à jour de statut ou d’une tâche terminée. | ||
| Pourquoi est-ce important ? L’analyse du temps consacré aux vérifications de crédit permet de repérer les goulots d’étranglement dans l’approbation des commandes. Elle est essentielle au KPI « Délai entre la vérification du crédit et la confirmation ». Où trouver ces données L’événement peut être déduit des changements de statut de la commande, par exemple lorsqu’elle passe au statut « En attente d’approbation du crédit », ou d’un journal d’événements explicite dans la fonctionnalité de gestion du crédit. Données à recueillir 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édez à Oracle BI Publisher : Connectez-vous à votre environnement Oracle Fusion avec un compte 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éez 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éfinissez le jeu de données de la requête SQL : Dans l’éditeur de modèle de données, cliquez sur l’icône « + » pour créer un 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.
- Saisissez 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 comprend les paramètres de date de début et de fin (:p_start_date et :p_end_date), que BI Publisher reconnaîtra automatiquement.
- Configurez 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 de 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.
- Affichez et enregistrez le modèle de données : Cliquez sur l’onglet « Data ». Il se peut que vous deviez 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 en cliquant sur l’icône d’enregistrement et attribuez-lui un nom explicite, par exemple « OrderToCash_EventLog_DM ».
- Créez 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 le coin supérieur droit. L’assistant de création de rapport s’ouvre.
- Configurez le rapport : Dans l’assistant, sélectionnez l’option « Use Data Model ». Suivez les instructions pour définir la mise en page. Pour un simple export CSV, choisissez 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, par exemple « OrderToCash_EventLog_Report ».
- Exécutez le rapport : Ouvrez le rapport que vous venez de créer. Vous serez invité à saisir les dates de début et de fin de l’extraction. Indiquez la période souhaitée.
- Exportez les données : Une fois le rapport exécuté, cliquez sur le menu déroulant « View » et sélectionnez une autre option d’affichage, comme « View Report ». Repérez ensuite le lien ou l’icône « Export » et choisissez « CSV » comme format d’export. Le fichier du journal d’événements sera téléchargé.
- Préparez l’importation : 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 importé 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 dans BI Publisher, comme « BI Administrator » ou « BI Author ».
- Source de données : La requête est conçue pour la source de données standard de l’application « 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 une période de 3 à 6 mois, afin d’éviter les délais d’expiration des rapports et les problèmes de performances.
- 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 les données selon un ID d’unité opérationnelle précis (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 les très grands jeux de données couvrant plusieurs années, cette requête unique 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.
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édez à la console BICC : Connectez-vous à votre instance Oracle Fusion Applications avec un compte disposant du rôle BICC_ADMINISTRATOR. Accédez à Tools, puis sélectionnez Business Intelligence Cloud Connector dans le menu.
- Créez une offre : Dans la console BICC, cliquez sur Configure External Storage pour configurer la destination. Il peut s’agir d’Oracle Universal Content Management (UCM) ou d’un compartiment OCI Object Storage. Vérifiez l’exactitude des informations de connexion et des identifiants.
- Lancez un nouveau travail d’extraction : Accédez à la section Manage Extract Jobs. Cliquez sur l’icône + pour créer un travail. Donnez-lui un nom explicite, par exemple ProcessMind_O2C_SalesOrder_Extract.
- Sélectionnez les Data Stores (PVO) : Dans la configuration du travail, recherchez et ajoutez les Public View Objects (PVO) nécessaires pour suivre le cycle de vie des commandes clients. Vous devrez en ajouter plusieurs, notamment FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice et FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Configurez les colonnes de chaque PVO : Pour chaque PVO sélectionné, cliquez sur le menu Actions et choisissez Select Columns. Sélectionnez avec soin les colonnes nécessaires à la création du journal d’événements, comme 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.
- Appliquez 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 la première exécution, vous pouvez choisir une période étendue. Pour les exécutions planifiées suivantes, configurez ce filtre afin de n’extraire que les enregistrements modifiés depuis le dernier travail.
- Planifiez le travail d’extraction : Accédez à la section Manage Schedule et créez un calendrier pour votre travail. Il est recommandé de l’exécuter en dehors des heures de pointe, par exemple chaque nuit, afin de limiter son impact sur les performances du système.
- Soumettez et suivez le travail : Une fois la configuration terminée, soumettez le travail. Vous pouvez suivre son avancement depuis l’écran Manage Extract Jobs. Une fois l’exécution terminée, les fichiers de données seront disponibles dans l’emplacement de stockage cloud configuré, au format CSV compressé.
- Transformez 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 traiter ces fichiers à l’aide d’un outil externe, comme Python, un script de base de données ou une plateforme ETL. Cette opération consiste à :
- Joindre les données de différents fichiers, par exemple en reliant les données de facture à l’en-tête de la commande client.
- Transformer les colonnes de date en lignes d’activité distinctes. Par exemple, à partir du fichier FscmTopModelAM.DooTopAM.Header, créez une ligne « Commande client créée » à partir de CreationDate et une autre « Commande clôturée » à partir de ClosedDate.
- Associer les codes de statut ou les indicateurs aux activités correspondantes, comme « Commande confirmée » ou « Commande annulée ».
- Regrouper toutes les données transformées dans un seul fichier comportant les colonnes requises : SalesOrder, ActivityName et EventTime.
- Préparez le fichier pour l’importation : Vérifiez que le fichier transformé final est un fichier CSV unique dont les colonnes correspondent aux attributs requis et recommandés. Vous pouvez maintenant l’importer dans ProcessMind.
Configuration
- Sélection des PVO : La précision du journal d’événements dépend entièrement du choix des PVO appropriés. Parmi les PVO importants figurent 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. Il est essentiel pour les performances et évite d’extraire plusieurs fois le même jeu de données de plusieurs gigaoctets. Le chargement complet initial sert de référence ; les exécutions suivantes ne récupèrent 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 concilier exhaustivité et volume raisonnable. Les exécutions suivantes seront incrémentielles.
- Configuration du stockage : BICC peut exporter les données vers UCM d’Oracle ou OCI Object Storage. OCI Object Storage est généralement recommandé pour les extractions en masse et facilite l’intégration avec les outils ETL en aval.
- Planification des travaux : Planifiez les travaux 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 le travail doivent disposer du rôle BICC_ADMINISTRATOR. Vous devez également avoir configuré au préalable les identifiants du stockage cloud et bien comprendre les transformations à effectuer après l’extraction.
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 organiser la collecte de vos données et commencer votre démarche de Process Mining. Commencez dès aujourd’hui à optimiser le traitement des commandes clients, de la commande à l’encaissement.
Optimisez dès aujourd’hui le traitement des commandes clients, de la commande à l’encaissement
Repérez les goulots d’étranglement et réduisez facilement de 30 % le temps de cycle de la commande à l’encaissement.
Aucune carte bancaire requise. Essai gratuit de 14 jours.