Votre modèle de données Commande à l'encaissement : Traitement des facturess factures fournisseurs factures fournisseurs commandes de vente
Votre modèle de données Commande à l'encaissement : Traitement des facturess factures fournisseurs factures fournisseurs commandes de vente
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide pratique d'extraction de données
De la commande au paiement - Attributs de Traitement des facturess factures fournisseurs factures fournisseurs commandes clients
| Nom | Descriptionn | ||
|---|---|---|---|
| Commande client SalesOrder | L'identifiant unique d'une commande client, servant de cas principal pour le processus de la commande au paiement. | ||
| Descriptionn Le numéro de commande client identifie de manière unique chaque commande client tout au long de son cycle de vie. Il agit comme le élément central connectant toutes les activités liées, de la création et confirmation initiales à l'exécution, la facturation et le paiement final. Dans le Process Mining, cet attribut est indispensable pour regrouper tous les événements liés en un seul cas. L'analyse du processus par commande client permet une vision globale complet, permettant le calcul des temps de cycle totaux, l'identification des variantes de processus pour les commandes individuelles et le suivi du parcours d'une commande à travers différents départements et systèmes. Pourquoi est-ce important ? : C'est l'ID de Cas. Il relie tous les événements du processus entre eux, permettant de tracer le parcours complet d'une seule commande client. Source des données : Cet identifiant se trouve généralement dans la table d'en-tête des commandes clients dans Oracle Fusion, telle que DOO_HEADERS_ALL. Consultez la documentation d'Oracle Fusion Financials. Exemples SO-100567SO-100568SO-100569 | |||
| Heure de l'événement EventTime | L'horodatage indiquant quand une activité ou un événement spécifique s'est produit pour une commande client. | ||
| Descriptionn Cet attribut fournit la date et l'heure de chaque activité du processus, établissant la séquence chronologique des événements. Il est la base temporelle de l'analyse des processus, enregistrant exactement quand chaque étape s'est produite. Dans le Process Mining, l'(EventTime) est indispensable pour le calcul des temps de cycle, des durées entre les activités et des délais globaux des cas. Il permet l'analyse des performances, la détection des points de blocage basée sur les temps d'attente, et le suivi de la conformité aux accords de niveau de service (SLA) liés aux délais. Tous les KPI et dashboards basés sur le temps dépendent de la précision de cet attribut. Pourquoi est-ce important ? : Cet horodatage est indispensable pour ordonner les événements chronologiquement et calculer toutes les métriques temporelles, telles que les temps de cycle et les durées. Source des données : C'est un attribut dérivé, provenant de divers champs d'horodatage à travers différentes tables Oracle Fusion, tels que la date de création de commande, la date d'expédition, la date de facture et la date de paiement. Exemples 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Nom de l'activité ActivityName | Le nom de l'événement commercial ou de la tâche spécifique qui s'est produit au sein du processus de commande client. | ||
| Descriptionn Cet attribut décrit l'étape qui a été exécutée à un moment précis pour une commande client, telle que 'Commande Client Créée', 'Marchandises Expédiées' ou 'paiement reçu'. La séquence de ces activités forme le flux de processus pour chaque cas. L'analyse de l'(ActivityName) est clée pour le Process Mining. Elle facilite la visualisation de la cartographie des processus, la découverte de différentes variantes de processus et l'identification des points de blocage où les cas s'accumulent. Elle est la base pour le calcul des temps de transition entre les étapes et la compréhension de la séquence opérationnelle du processus de la commande au paiement. Pourquoi est-ce important ? : Cet attribut définit les étapes de la cartographie des processus, pour visualiser et l'analyse du flux de processus. Source des données : C'est un attribut dérivé, construit en mappant les statuts de transaction ou les types d'événements de diverses tables Oracle Fusion (par exemple, statut de commande, statut d'expédition, statut de facture) à une liste standardisée de noms d'activités. Exemples Commande client crééeMarchandises expédiéesFacture crééepaiement reçu | |||
| Canal de vente SalesChannel | Le canal par lequel la commande client a été reçue. | ||
| Descriptionn Cet attribut catégorise l'origine de la commande client, telle que 'Web', 'Ventes Directes', 'Partenaire' 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 indispensable pour le tableau de bord 'Vue d'ensemble des performances des canaux de vente'. Elle aide à comparer l'efficacité, les temps de cycle et les taux d'erreur des différents canaux pour identifier ceux qui sont les plus efficaces et ceux qui peuvent nécessiter des améliorations de processus ou une automatisation supplémentaire. Pourquoi est-ce important ? : Prend en charge l'analyse des performances par canal, aidant à identifier les canaux les plus et les moins efficaces pour le traitement des commandes. Source des données : Cette information peut être stockée dans un champ dédié sur l'en-tête de la commande client. Consultez la documentation d'Oracle Fusion Financials. Exemples Ventes DirectesPortail webEDIRevendeur | |||
| Date d'échéance du paiement PaymentDueDate | La date à laquelle le client est tenu d'effectuer le paiement de la facture. | ||
| Descriptionn La date d'échéance de paiement est calculée sur la base de la date de la facture et des conditions de paiement convenues avec le client. Elle fixe la date limite pour un recouvrement rapide des paiements. Cet attribut est impératif pour le KPI 'Taux de recouvrement des paiements à temps'. En comparant la PaymentDueDate avec la date réelle de réception du paiement, le système peut déterminer si un paiement a été effectué à temps ou en retard, aidant à surveiller la performance des comptes clients et à gérer les flux de trésorerie. Pourquoi est-ce important ? : Sert de date limite pour le calcul des taux de paiement à temps, ce qui est une mesure clé de l'efficacité des flux de trésorerie. Source des données : Trouvé dans les tables de comptes débiteurs ou de factures d'Oracle Fusion, telles que Exemples 2023-06-192023-07-012023-06-25 | |||
| Date de livraison demandée RequestedDeliveryDate | La date de livraison de la commande telle que demandée par le client. | ||
| Descriptionn Cet attribut enregistre la date à laquelle le client souhaite recevoir les marchandises. Elle sert d'objectif de performance clé pour la partie exécution du processus de la commande au paiement. Cette date est indispensablele pour calculer le KPI 'Taux de paiement à temps' et pour soutenir le tableau de bord 'accord de niveau de service (SLA) de livraison'. En comparant cette date avec la ActualDeliveryDate, l'organisation peut mesurer sa capacité à répondre aux attentes des clients et identifier les causes profondes des retards de livraison. Pourquoi est-ce important ? : Sert de référence pour mesurer la performance de paiement à temps et la conformité aux accords de niveau de service (SLA) client. Source des données : Généralement situé dans les tables de lignes de commandes clients dans Oracle Fusion. Consultez la documentation d'Oracle Fusion Financials. Exemples 2023-05-202023-06-012023-05-25 | |||
| Date de livraison réelle ActualDeliveryDate | La date à laquelle les marchandises ont été effectivement livrées au client. | ||
| Descriptionn Cet attribut enregistre la date de livraison finale, qui marque l'achèvement de la partie exécution du processus. C'est le résultat réel par rapport auquel les dates planifiées ou demandées sont mesurées. Cette date est comparée à la RequestedDeliveryDate pour calculer la performance de paiement à temps. Elle est une entrée critique pour le KPI 'Taux de paiement à temps' et le tableau de bord 'SLA de livraison', fournissant une mesure claire de l'efficacité de la logistique et de la chaîne d'approvisionnement. Pourquoi est-ce important ? : C'est la date de résultat réelle utilisée pour calculer les taux de paiement à temps et évaluer la performance d'exécution par rapport aux demandes des clients. Source des données : Provient des tables de transactions d'expédition et de livraison dans Oracle Fusion. Consultez la documentation d'Oracle Fusion Financials. Exemples 2023-05-202023-06-032023-05-25 | |||
| Est Automatisé IsAutomated | Un indicateur signalant si une activité a été effectuée automatiquement par le système ou manuellement par un utilisateur. | ||
| Descriptionn Cet attribut booléen distingue les événements pilotés par le système (par exemple, contrôle de crédit automatisé, facture générée par le système) et les actions manuelles de l'utilisateur. Il est généralement dérivé en fonction du nom d'utilisateur associé à une activité, où un ID système génériqueique indique l'automatisation. L'analyse de cet attribut aide à mesurer le niveau d'automatisation dans le processus et est une entrée directe pour le KPI 'Pourcentage de commandes repriseslées manuellement'. Il peut mettre en évidence les opportunités d'automatisation supplémentaire en montrant quelles étapes manuelles sont les plus chronophages ou sujettes aux erreurs. Pourquoi est-ce important ? : Aide à quantifier le niveau d'automatisation du processus et à identifier les opportunités de réduire les coûteuses interventions manuelles. Source des données : C'est un champ dérivé, souvent basé sur une règle appliquée à l'attribut UserName. Par exemple, si l'utilisateur est 'SYSTEM' ou 'BATCH', ce drapeau est défini à vrai. Exemples truefaux | |||
| Montant total de la commande client SalesOrderTotalAmount | La valeur monétaire totale de la commande de vente. | ||
| Descriptionn Cet attribut représente le montant total facturé au client pour l'ensemble de la commande client. Il inclut la somme de toutes les lignes d'articles, taxes et autres frais, avant toute application de remises. Dans l'analyse des processus, cet attribut est impératif pour le Process Mining basé sur la valeur. Il permet de segmenter les commandes par valeur (par exemple, commandes de grande valeur vs commandes de faible valeur) pour voir si elles suivent différents chemins de processus ou ont des temps de cycle différents. Il aide également à prioriser les efforts d'amélioration des processus sur les cas les plus significatifs financièrement. Pourquoi est-ce important ? : Permet l'analyse d'impact financier, aidant à prioriser les améliorations de processus sur les commandes de grande valeur et à comprendre les facteurs de coût. Source des données : Généralement disponible dans les tables d'en-tête de commandes clients dans Oracle Fusion. Consultez la documentation d'Oracle Fusion Financials. Exemples 5250.00125000.75980.50 | |||
| Nom d'utilisateur UserName | Le nom ou l'`ID` de l'`utilisateur` qui a effectué l'activité. | ||
| Descriptionn Cet attribut identifie l'employé ou l'utilisateur système responsable de l'exécution d'une étape de processus spécifique. Il peut être utilisé pour analyser les performances au niveau de l'utilisateur, la répartition de la charge de travail et le respect des procédures standard. L'analyse par utilisateur aide à identifier les besoins en formation, à reconnaître les individus ou les équipes très performants et à enquêter sur les écarts causées par des utilisateurs spécifiques. Elle est également précieuse à des fins de conformité et d'audit pour suivre qui a effectué quelles actions. Pourquoi est-ce important ? : Permet l'analyse des performances par utilisateur, de la répartition de la charge de travail et l'identification des schémas de reprises manuel liés aux individus. Source des données : Généralement issu de champs comme CREATED_BY ou LAST_UPDATED_BY dans les tables de transactions Oracle Fusion, souvent lié à une table maîtresse d'utilisateurs comme FND_USER. Exemples john.smithjane.doesystem_batch_user | |||
| Nom du client CustomerName | Le nom du client ayant passé la commande de vente. | ||
| Descriptionn Cet attribut identifie le nom légal du compte client associé à la commande client. C'est une dimension clé pour segmenter et analyser le processus selon une approche orientée client. L'analyse par client aide à identifier si certains clients connaissent des temps de cycle plus longs, plus de reprises ou des écarts de processus spécifiques. Cette information peut être utilisée pour améliorer le service client, adapter les processus pour les comptes clés et enquêter sur les problèmes affectant la satisfaction client. Pourquoi est-ce important ? : Permet une analyse orientée client.ur identifier les problèmes de processus affectant des clients spécifiques et améliorer la satisfaction client. Source des données : Provient des tables de données de base clients (par exemple, HZ_PARTIES) et est lié à la commande client via un ID client. Exemples Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Conditions de paiement PaymentTerms | Les conditions convenues pour le paiement du client. | ||
| Descriptionn Cet attribut spécifie les conditions dans lesquelles un client est censé payer sa facture, par exemple, 'Net 30' ou 'Net 60'. Ces conditions sont la base du calcul de la PaymentDueDate. En analyse, la segmentation par conditions de paiement peut aider à expliquer les variations des temps de cycle de paiement. Elle fournit un contexte pour le KPI 'Taux de paiement ponctuel', car différentes conditions conduisent naturellement à différents comportements de paiement. Cela peut éclairer la politique de crédit et la prévision des flux de trésorerie. Pourquoi est-ce important ? : Fournit un contexte essentiel pour l'analyse du comportement de paiement et aide à expliquer les variations des temps de cycle de la facture au paiement. Source des données : Disponible au niveau de la commande client ou du compte client dans Oracle Fusion. Consultez la documentation d'Oracle Fusion Financials. Exemples Net 30Net 60Dû à la réception | |||
| Dernière mise à jour des données LastUpdateDate | L'horodatage indiquant la dernière fois que les données de cet événement ont été actualisées à partir du système source. | ||
| Descriptionn Cet attribut enregistre la dernière date d'extraction ou de mise à jour des données dans le jeu de données du Process Mining. Il assure la transparence sur la la réactualisation des données analysées. Cette information est fondamentale pour que les utilisateurs comprennent l'actualité de l'analyse des processus. Elle aide à gérer les attentes concernant la réactualisation des données et est importante pour la mise en place et le suivi des calendriers d'actualisation des données. Pourquoi est-ce important ? : Indique la la réactualisation des données, garantissant aux utilisateurs de savoir à quel point leur analyse de processus est à jour. Source des données : Cette valeur est générée et estampillée sur le 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 | |||
| Est un paiement en retard IsLatePayment | Un indicateur calculé qui est vrai si le paiement a été reçu après la date d'échéance du paiement. | ||
| Descriptionn Cet attribut booléen est dérivé en comparant la date de réception effective du paiement avec la PaymentDueDate. Il fournit un indicateur clair de si une facture a été payée à temps. Cet attribut est utilisé pour calculer le KPI 'Taux de paiement ponctuel'. Il permet une segmentation facile des paiements à temps vs en retard pour analyser les caractéristiques des clients payeurs tardifs, les raisons courantes des retards et l'impact financier sur le fonds de roulement. Pourquoi est-ce important ? : Mesure directement l'efficacité du recouvrement des paiements « what-if »mplifie l'analyse des paiements en souffrance. Source des données : C'est un champ calculé. La logique est : PaymentReceivedDate > PaymentDueDate. Exemples fauxtrue | |||
| Est une livraison ponctuelle IsOnTimeDelivery | Un indicateur calculé qui est vrai si la livraison réelle a eu lieu à la date de livraison demandée ou avant. | ||
| Descriptionn Cet attribut booléen est dérivé en comparant la ActualDeliveryDate avec la RequestedDeliveryDate. Il fournit un indicateur simple, au niveau du cas, de la performance de livraison. Ce drapeau est la base pour calculer le KPI agrégé 'Taux de paiement à temps'. Il simplifie le filtrage et l'analyse, permettant aux utilisateurs d'isoler rapidement toutes les commandes en retard pour effectuer une analyse des causes profondes des facteurs contribuant aux retards. Pourquoi est-ce important ? : Mesure directement la performance de l'exécution par rapport aux attentes du client « what-if »mplifie l'analyse des commandes en retard. Source des données : C'est un champ calculé. La logique est : ActualDeliveryDate <= RequestedDeliveryDate. Exemples truefaux | |||
| Facture corrigée ? IsInvoiceCorrected | Un indicateur signalant si une facture a été corrigée ou révisée après sa création initiale. | ||
| Descriptionn Cet attribut booléen est vrai si une facture a subi une boucle de correction, indiqué par la présence d'une activité 'Facture Corrigée'. Il signale les cas qui ont impliqué un reprises au stade de la facturation. Ceci est une entrée clé pour le tableau de bord 'Analyse de la précision et du reprises des factures' et le KPI 'Taux de reprises des factures'. Il aide à quantifier l'étendue des erreurs de facturation et permet une analyse des causes profondes pour identifier pourquoi des corrections sont nécessaires, visant à réduire le travail manuel et les retards de paiement. Pourquoi est-ce important ? : Identifie les reprises de facture, un indicateur clé d'inefficacité des processus, de problèmes de qualité des données et de retards potentiels de paiement. Source des données : C'est un champ calculé, généralement défini à vrai pour un cas si une activité 'Facture Corrigée' existe dans son journal d'événements. Exemples fauxtrue | |||
| Méthode d'expédition ShippingMethod | La méthode ou le transporteur utilisé pour expédier les marchandises au client. | ||
| Descriptionn Cet attribut détaille le transporteur logistique ou le niveau de service utilisé pour la livraison, tels que 'Fret terrestre', 'Air Express' ou 'Courrier local'. Cette information est indispensablele pour le tableau de bord 'Conformité de la livraison par méthode d'expédition'. Elle permet la comparaison des performances de paiement à temps et des coûts d'expédition entre différentes méthodes et transporteurs, aidant à optimiser la stratégie logistique et la sélection des fournisseurs. Pourquoi est-ce important ? : Facilite l'analyse logistique en permettant la comparaison des performances de différents transporteurs et méthodes d'expédition. Source des données : Disponible dans les tables d'expédition et d'exécution d'Oracle Fusion. Consultez la documentation d'Oracle Fusion Financials. Exemples FedEx GroundUPS Next Day AirDHL International | |||
| Nom du Produit ProductName | Le nom du produit ou service vendu. | ||
| Descriptionn Cet attribut spécifie l'article sur la ligne de commande client. Si une commande a plusieurs lignes, le cas peut être analysé au niveau de l'article de ligne, ou cet attribut pourrait être agrégé au niveau de l'en-tête. L'analyse par produit aide à comprendre si certains produits sont associés à des flux de processus plus complexes ou problématiques, tels que des retards de livraison fréquents ou des problèmes de paiement. Cela peut éclairer les stratégies de gestion de produit et de chaîne d'approvisionnement. Pourquoi est-ce important ? : Permet l'analyse de la performance des processus pour différents produits, en mettant en évidence les articles qui peuvent avoir des chemins de réalisation ou de facturation complexes. Source des données : Provient des tables de lignes de commande client et est joint à une table de produits maîtres. Consultez la documentation d'Oracle Fusion Financials. Exemples Standard Widget X1Premium Service PackageComposant Y2-B | |||
| Numéro de facture InvoiceNumber | L'identifiant unique de la facture client. | ||
| Descriptionn Cet attribut est le 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 règlement financier du processus. Bien que la commande client soit l'ID de cas principal, le numéro de facture est indispensable pour analyser les sous-processus de facturation et de paiement. Il est indispensable pour suivre les corrections de facture, les litiges et le statut de paiement, soutenant des dashboards comme 'Analyse de la précision et du reprises des factures'. Pourquoi est-ce important ? : Fournit un lien crucial vers le processus des comptes clients et est nécessaire pour analyser les reprises des factures et les cycles de paiement. Source des données : Disponible dans les tables de transactions des comptes débiteurs d'Oracle Fusion, telles que Exemples INV-93485INV-93486INV-93487 | |||
| Pays du client CustomerCountry | Le pays où le client est situé. | ||
| Descriptionn Cet attribut fournit le pays de l'adresse de livraison ou de facturation du client. C'est une dimension clé pour l'analyse géographique. La segmentation du processus par pays peut révéler des différences régionales en termes de performance des processus, de temps de cycle ou de comportement de paiement. Ceci est précieux pour comprendre l'impact des réglementations locales, des défis logistiques et des conditions du marché sur le processus de la commande au paiement. Pourquoi est-ce important ? : Permet une analyse géographique pour identifier les variations régionales en matière d'efficacité des processus, de conformité et de comportement client. Source des données : Provient des tables de données de base clients (HZ_LOCATIONS, HZ_PARTY_SITES) liées à la commande client. Exemples États-UnisAllemagneJapon | |||
| Système source SourceSystemIdentifier | Identifie le système source d'où les données d'événement ont été extraites. | ||
| Descriptionn Cet attribut spécifie l'origine des données, ce qui est particulièrement utile dans les environnements où plusieurs systèmes sont impliqués dans le processus de la commande au paiement. Par exemple, les données de commande peuvent provenir d'Oracle Fusion, tandis que les données d'expédition pourraient provenir d'un système logistique tiers. En analyse, cela aide à comprendre la traçabilité des données et peut être utilisé pour filtrer la vue du processus pour les événements provenant de systèmes spécifiques. Il est impératif pour la validation des données et pour l'identification de la fragmentation des processus à travers différents paysages informatiques. Pourquoi est-ce important ? : Fournit un contexte sur l'origine des données, ce qui est impératif pour la gouvernance des données et le dépannage dans des environnements multi-systèmes. Source des données : Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter l'origine du jeu de données. Exemples Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Type de commande OrderType | Une classification pour la commande client, telle que 'Commande Standard' ou 'Commande de Retour'. | ||
| Descriptionn Le type de commande est utilisé pour catégoriser les commandes clients en fonction de leur objectif commercial. Les types courants incluent les ventes standard, les commandes de service, les autorisations de retour de matériel (RMA) et les commandes internes. L'analyse du processus par type de commande est importante car différents types ont souvent des flux de processus et des objectifs de performance distincts. Cette segmentation aide à comprendre les variations de processus qui sont intentionnelles et attendues, évitant ainsi qu'elles ne soient mal interprétées comme des écarts. Pourquoi est-ce important ? : Permet la segmentation des différents flux de processus légitimes (par exemple, standard vs retours) pour garantir une analyse juste et précise. Source des données : Généralement disponible en tant que champ dans la table d'en-tête de la commande client dans Oracle Fusion. Consultez la documentation d'Oracle Fusion Financials. Exemples Commande client standardAutorisation de retourOrdre de service | |||
| Unité commerciale BusinessUnitName | Le nom de l'unité commerciale interne responsable de la commande client. | ||
| Descriptionn Cet attribut représente la division ou l'unité opérationnelle spécifique dans l'entreprise qui possède la transaction. Il permet une comparaison des performances entre différentes parties de l'organisation. La segmentation du processus par unité commerciale aide à identifier les variations d'efficacité, de coût et de conformité dans l'entreprise. Cette analyse peut révéler les meilleures pratiques dans les unités très performantes qui peuvent être partagées, ou mettre en évidence les unités sous-performantes qui nécessitent des améliorations de processus ciblées. Pourquoi est-ce important ? : Permet l'analyse comparative des performances et l'analyse de la cohérence des processus danss différentes unités organisationnelles. Source des données : Généralement disponible sur l'en-tête de la commande client et lié à la structure organisationnelle définie dans Oracle Fusion. Exemples BU-North AmericaBU-EMEAServices mondiaux | |||
De la commande au paiement - Activités de Traitement des facturess factures fournisseurs factures fournisseurs commandes clients
| Activité | Descriptionn | ||
|---|---|---|---|
| Commande client créée | Cette activité marque le début du processus de commande client, représentant le moment où une nouvelle commande client est saisie dans Oracle Fusion. Cet événement est généralement capturé explicitement lorsqu'un utilisateur enregistre un nouvel enregistrement de commande dans le module de gestion des commandes. | ||
| Pourquoi est-ce important ? : En tant que début du processus, cette activité est indispensablele pour mesurer le temps de cycle global de l'Order-to-Cash et analyser les volumes d'entrée de commandes. Source des données : Comptabilisé explicitement lors de la création d'un enregistrement de commande client dans Gestion des commandes Cloud. Recherchez les horodatages de création dans la table DOO_HEADERS_ALL. Capture Capturé à partir de l'horodatage de création de l'enregistrement d'en-tête de commande client. Type d'événement explicit | |||
| Commande Clôturée | L'activité finale du processus, indiquant que 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 est mis à jour à 'Clôturé'. | ||
| Pourquoi est-ce important ? : Cette activité marque la fin réussie du cycle de vie de la commande client. Elle est indispensablele pour calculer les durées de processus complet et identifier les commandes "zombies" qui ne se ferment jamais. Source des données : Déduit du changement de statut de l'en-tête de la commande client à 'Clôturé' dans la table Capture Déduit de l'horodatage du changement de statut à 'Clôturé' sur l'en-tête de la commande client. Type d'événement inferred | |||
| Commande Confirmée | Ce jalon clé signifie que la commande client a passé toutes les vérifications initiales, y compris l'approbation de crédit, et est maintenant engagée pour exécution. Il est généralement inféré lorsque le statut de la commande progresse vers un état comme 'En attente d'expédition' ou 'Planifiée'. | ||
| Pourquoi est-ce important ? : Cette activité est un jalon critique pour le calcul du 'Temps moyen de confirmation de commande' et marque le passage de la saisie de commande au processus d'exécution. Source des données : Déduit d'un changement de statut de l'en-tête ou de la ligne de commande client vers une valeur indiquant qu'elle est prête pour l'exécution (par exemple, 'En attente d'expédition'). Vérifiez les colonnes de statut dans Capture Déduit de l'horodatage lorsque le statut de la commande passe à un état confirmé ou planifié. Type d'événement inferred | |||
| Facture créée | Cette activité représente la création de la facture client dans le module des comptes clients, 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 est-ce important ? : Marque le début officiel du cycle de recouvrement des paiements. C'est la base pour mesurer le 'Temps de la facture au paiement' et l'efficacité globale de la trésorerie. Source des données : C'est un événement explicite dans Oracle Comptes Clients (AR). Un enregistrement de facture est créé dans la table RA_CUSTOMER_TRX_ALL avec une date de transaction. Capture 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 ont été expédiées de l'entrepôt et sont en transit vers le client. Elle est capturée lorsqu'une transaction de confirmation d'expédition est traitée dans Oracle Shipping. | ||
| Pourquoi est-ce important ? : C'est un jalon critique qui signifie l'achèvement de la partie exécution du processus et déclenche la facturation. Il est indispensable pour mesurer les délais d'expédition et de paiement à temps. Source des données : C'est un événement explicite enregistré dans Oracle Shipping Execution. La transaction de confirmation d'expédition crée un enregistrement dans les tables d'expédition comme WSH_DELIVERY_DETAILS avec une date d'expédition. Capture Capturé à partir de l'horodatage de la 'date d'expédition réelle' sur l'enregistrement de détail de livraison associé à la ligne de commande. Type d'événement explicit | |||
| paiement reçu | Cette activité signifie que le paiement du client a été reçu et appliqué à la facture dans les comptes clients. Ceci est capturé lorsqu'une application d'encaissement est enregistrée. | ||
| Pourquoi est-ce important ? : C'est un jalon critique pour mesurer le 'Temps de cycle global de la commande au paiement' et le 'Taux de paiement ponctuel'. Il représente la conversion de la vente en liquidités. Source des données : C'est un événement explicite dans Oracle Comptes Clients. Il est enregistré dans les tables de reçus de trésorerie comme AR_RECEIVABLE_APPLICATIONS_ALL lorsqu'un reçu est appliqué à une facture. Capture Capturé à partir de l'horodatage de la 'date d'application' de l'enregistrement d'application d'encaissement dans les comptes débiteurs (AR). Type d'événement explicit | |||
| Commande Annulée | Représente l'annulation d'une commande client avant qu'elle ne soit entièrement expédiée. Cela peut se produire pour diverses raisons et se traduit par un statut final de 'Annulé'. | ||
| Pourquoi est-ce important ? : C'est un chemin d'exception critique. L'analyse des commandes annulées aide à identifier les causes profondes, telles que les ruptures de stock, les problèmes de prix ou les changements d'avis des clients, qui peuvent éclairer les améliorations de processus. Source des données : Déduit du changement de statut de l'en-tête ou de la ligne de commande client à un état 'Annulé'. L'horodatage de ce changement de statut est utilisé pour enregistrer l'événement. Capture Déduit de l'horodatage du changement de statut à 'Annulé' sur l'en-tête ou la ligne de commande. Type d'événement inferred | |||
| Facture Corrigée | 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 clients. Ceci est généralement enregistré 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 indispensable pour le KPI 'Taux de reprises des factures', mettant en évidence les problèmes dans le processus de facturation qui peuvent retarder les paiements et augmenter les coûts administratifs. Source des données : Déduit par la création d'un avoir (lié à la facture originale) ou d'une version ultérieure de la même facture dans la table Capture Déduit en identifiant les notes de crédit ou les factures qui font référence à une transaction de facture précédente. Type d'événement inferred | |||
| Ligne de commande clôturée | Représente la clôture finale d'une ligne de commande client individuelle, indiquant qu'elle a été entièrement expédiée, facturée et qu'aucune autre transaction n'est attendue. Le système met à jour le statut de la ligne à 'Clôturée'. | ||
| Pourquoi est-ce important ? : La clôture des lignes de commande signifie l'achèvement de toutes les obligations contractuelles pour cet article. L'analyse de ceci aide à identifier les commandes qui restent ouvertes longtemps après l'exécution et le paiement. Source des données : Déduit du changement de statut de la ligne d'exécution à 'Clôturé' dans la table Capture Déduit de l'horodatage du changement de statut à 'Clôturé' sur la ligne d'exécution. Type d'événement inferred | |||
| Marchandises livrées | Indique que le client a reçu l'envoi. Cette information provient souvent d'un transporteur externe et est mise à jour dans Oracle Fusion, ou elle peut être déduite sur la base d'un temps de transit standard à partir de la date d'expédition. | ||
| Pourquoi est-ce important ? : Cette activité est indispensablele pour le calcul du KPI 'Taux de paiement à temps' et la mesure précise des niveaux de service client. Source des données : Ce n'est souvent pas un événement natif d'Oracle. Il peut être capturé si une intégration transporteur est en place, ou calculé en ajoutant un temps de transit standard à la date de 'Marchandises Expédiées'. Nécessite une analyse système. Capture Déduit des flux de données du transporteur ou calculé en fonction de la date d'expédition plus un temps de transit moyen. Type d'événement inferred | |||
| Marchandises prélevées | Représente le prélèvement physique des marchandises dans l'entrepôt pour exécuter la commande. C'est une étape clé dans le processus logistique et est généralement enregistré dans le module de gestion d'entrepôt ou d'expédition. | ||
| Pourquoi est-ce important ? : Cette activité offre une visibilité sur les opérations d'entrepôt. Les retards entre la réservation des stocks et le prélèvement peuvent indiquer des points de blocage de ressources ou de processus dans l'entrepôt. Source des données : Capturé danss modules Oracle Fusion Cloud SCM (Supply Chain Management). Il peut être déduit du changement de statut d'une vague de prélèvement.lèvement ou d'un bon de prélèvement.lèvement associé à la ligne de commande client. Capture Déduit de l'horodatage d'achèvement de la transaction de prélèvement.lèvement dans les modules SCM. Type d'événement inferred | |||
| Stock Réservé | Cette activité représente l'allocation ou la réservation de stocks physiques pour exécuter la ligne de commande client. Le système engage un stock spécifique, garantissant sa disponibilité lorsque la commande est prête à être prélevée. | ||
| Pourquoi est-ce important ? : Le suivi de cela aide à analyser le KPI 'Délai d'allocation d'inventaire' et identifie les retards entre la confirmation de commande et la sécurisation des marchandises. Source des données : Cet événement est souvent capturé dans les modules d'inventaire ou d'exécution de la chaîne d'approvisionnement. Il peut être inféré des mises à jour de statut sur la ligne d'exécution indiquant que l'inventaire a été détaillé ou réservé. Capture Déduit des changements de statut des lignes d'exécution liés à la réservation ou à la planification des stocks. Type d'événement inferred | |||
| Suspension de Crédit Appliquée | Cette activité se produit lorsqu'une commande client est automatiquement ou manuellement mise en attente en raison d'un contrôle de crédit échoué ou d'un autre problème lié au crédit. Ceci est généralement capturé par un changement de statut de suspension de la commande au sein du système. | ||
| Pourquoi est-ce important ? : Le suivi des suspensions de crédit est impératif pour identifier les raisons des retards de traitement des commandes et pour mesurer l'efficacité du processus de levée des suspensions de crédit. Source des données : Déduit de l'application d'une retenue sur la commande client. Cela est généralement enregistré dans les tables liées aux retenues, telles que Capture Déduit de la création d'un enregistrement dans la table de retenues de commande avec un type de retenue 'Crédit'. Type d'événement inferred | |||
| Vérification de Crédit Effectuée | Représente l'exécution d'un contrôle de crédit sur le compte du client pour évaluer sa solvabilité. C'est souvent une étape automatisée ou manuelle dans le workflow de traitement des commandes, et sa complétion est généralement enregistrée comme une mise à jour de statut ou une tâche terminée. | ||
| Pourquoi est-ce important ? : L'analyse du temps consacré aux vérifications de crédit permet d'identifier les points de blocage dans l'approbation des commandes. Elle est indispensablele pour le KPI 'Temps de vérification de crédit à confirmation'. Source des données : Peut être déduit des changements de statut sur la commande client, comme le passage à un statut 'En attente d'approbation de crédit', ou d'un journal d'événements explicite dans la fonctionnalité de gestion du crédit. Capture Déduit des changements de statut des commandes ou des horodatages associés aux tâches de révision de crédit. Type d'événement inferred | |||
Guides d'extraction
Étapes
- Naviguer vers Oracle BI Publisher: Connectez-vous à votre environnement Oracle Fusion avec un utilisateur disposant des privilèges d'administrateur BI ou d'auteur BI. Utilisez le menu Navigateur pour accéder à Outils > Rapports et Analyses. Cliquez sur le bouton 'Parcourir le catalogue' pour ouvrir le catalogue Business Intelligence.
- Créer un nouveau modèle de données: Dans le catalogue BI, naviguez vers un dossier approprié (par exemple, Dossiers Partagés > Personnalisé). Cliquez sur le menu déroulant 'Nouveau' et sélectionnez 'Template de données'.
- Définir le jeu de données de requête SQL: Dans l'éditeur de modèle de données, cliquez sur l'icône '+' pour créer un nouveau jeu de données et sélectionnez 'Requête SQL'. Une boîte de dialogue apparaîtra. Nommez le jeu de données (par exemple, 'OrderToCash_EventLog'), sélectionnez 'Oracle BI EE' comme source de données et choisissez 'SQL standard' comme type de SQL.
- Saisir la requête SQL: Copiez la requête SQL complète fournie dans la section 'requête' de ce document et collez-la dans la zone de texte de la requête SQL. La requête inclut des paramètres pour la date de début et de fin (
:p_start_dateet: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'. Naviguez vers la section 'Propriétés' dans le volet gauche de l'éditeur de modèle de données. Assurez-vous que l'option 'Inclure les balises de paramètre' est cochée. Vous pouvez également définir des valeurs par défaut pour les paramètres de date si vous le souhaitez.
- Visualiser et sauvegarder le modèle de données: Cliquez sur l'onglet 'Données'. Il peut vous être demandé de saisir des valeurs pour les paramètres de date. Saisissez une petite plage de dates pour tester. Cliquez sur 'Afficher' pour voir un échantillon des données. Si les données apparaissent correctement, enregistrez le modèle de données en cliquant sur l'icône d'enregistrement et en lui donnant un nom descriptif (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 'Créer un rapport' dans le coin supérieur droit. Cela ouvrira l'assistant de création de rapport.
- Configurer le rapport: Dans l'assistant, sélectionnez l'option 'Utiliser le modèle de données'. L'assistant vous guidera à travers les paramètres de mise en page. Pour une exportation CSV simple, vous pouvez choisir la mise en page 'Table'. Faites glisser et déposez toutes les colonnes dans le tableau. Cliquez sur 'Suivant', puis décochez 'Afficher la ligne des totaux'. Cliquez sur 'Terminer' pour enregistrer le rapport. Donnez-lui un nom comme 'OrderToCash_EventLog_Report'.
- Exécuter le rapport: Ouvrez le rapport nouvellement créé. Il vous sera demandé de saisir les dates de début et de fin pour l'extraction. Fournissez la plage de dates souhaitée.
- Exporter les données: Une fois le rapport exécuté, cliquez sur le menu déroulant 'Afficher' et sélectionnez une option d'affichage différente, telle que 'Afficher le rapport'. Ensuite, trouvez le lien ou l'icône 'Exporter' et choisissez 'CSV' comme format d'exportation. Cela téléchargera le fichier journal d'événements.
- Préparer pour le téléchargement: Ouvrez le fichier CSV téléchargé. Vérifiez que les en-têtes de colonne correspondent aux attributs requis : SalesOrder, (ActivityName), (EventTime), UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate, et IsAutomated. Le fichier est maintenant prêt à être téléchargé dans l'outil de Process Mining.
Configuration
- Privilèges Utilisateur: Vous devez disposer d'un rôle avec les privilèges de modèle de données et de création de rapports BI Publisher, tels que 'BI Administrator' ou 'BI Author'.
- Source de Données: La requête est conçue pour la source de données d'application standard 'Oracle BI EE', qui se connecte à la base de données transactionnelle (Fusion Apps). Aucune configuration spéciale n'est généralement nécessaire.
- Paramètres de Plage de Dates: La requête utilise deux paramètres,
:p_start_dateet:p_end_date, pour filtrer les données. Il est fortement recommandé d'extraire les données par lots gérables, par exemple 3 à 6 mois à la fois, pour éviter les dépassements de temps de rapport et les problèmes de performance. - Filtrage par Unité Commerciale: Pour limiter la portée de l'extraction, vous pouvez ajouter une clause WHERE au CTE
BaseOrdersdans la requête pour filtrer par un ID d'unité commerciale spécifique (par exemple,AND dhead.SUBMITTING_BU_ID IN ([Votre ID d'unité commerciale])). - Filtrage par Type de Commande: Vous pouvez également filtrer par types de commandes spécifiques en ajoutant une condition sur
dhead.SOURCE_ORDER_TYPE_CODEdans le CTEBaseOrders. - Performance: Pour les jeux de données très volumineux s'étendant sur plusieurs années, cette approche à requête unique peut être lente. Envisagez de l'exécuter pendant les heures creuses ou de diviser l'extraction en lots mensuels plus petits. Assurez-vous que la propriété 'Enable SQL Pruning' n'est pas sélectionnée dans le modèle de données, car cela peut interférer avec 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. Naviguez vers Outils et sélectionnez Business Intelligence Cloud Connector dans le menu. - Créer une nouvelle offre: Dans la console BICC, cliquez sur Configurer le stockage externe pour définir votre destination cible, qui peut être Oracle Universal Content Management (UCM) ou un compartiment OCI Object Storage. Assurez-vous que vos détails de connexion et vos identifiants sont corrects.
- Lancer une nouvelle tâche d'extraction: Naviguez vers la section Gérer les tâches d'extraction. Cliquez sur l'icône + pour créer une nouvelle tâche. Donnez-lui un nom descriptif, par exemple,
ProcessMind_O2C_SalesOrder_Extract. - Sélectionner les magasins de données (PVOs): Dans la configuration de la tâche, recherchez et ajoutez les Public View Objects (PVOs) requis pour capturer le cycle de vie de la commande client. Vous devrez ajouter plusieurs PVOs, incluant FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice, et FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Configurer les colonnes pour chaque PVO: Pour chaque PVO sélectionné, cliquez sur le menu Actions et choisissez Sélectionner les colonnes. Sélectionnez avec soin les colonnes nécessaires pour générer le journal d'événements, telles que HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate, et les identifiants d'utilisateur. Référez-vous au manifeste de requête pour une liste détaillée des colonnes requises de chaque PVO.
- Appliquer des filtres pour les chargements incrémentiels: Pour gérer le volume de données, appliquez un filtre à chaque PVO basé sur la colonne LastUpdateDate. Pour la première exécution, vous pouvez sélectionner une large plage de dates. Pour les exécutions planifiées ultérieures, ce filtre doit être configuré pour extraire uniquement les enregistrements mis à jour depuis la dernière exécution de la tâche.
- Planifier la tâche d'extraction: Naviguez vers la section Gérer la planification. Créez une nouvelle planification pour votre tâche. Il est recommandé d'exécuter la tâche pendant les heures creuses, par exemple quotidiennement pendant la nuit, afin de minimiser l'impact sur les performances du système.
- S'inscrire et surveiller la tâche: Une fois configurée, soumettez la tâche. Vous pouvez suivre sa progression depuis l'écran Gérer les tâches d'extraction. Une fois terminée avec succès, les fichiers de données seront disponibles dans votre 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 de table brutes, pas un journal d'événements formaté. Vous devez utiliser un outil externe (comme Python, un script de base de données ou une plateforme ETL) pour traiter ces fichiers. Cela implique :
- Joindre les données de différents fichiers (par exemple, lier les données de facture à l'en-tête de la commande client).
- Pivoter les colonnes de date en lignes d'activité distinctes. Par exemple, à partir du fichier FscmTopModelAM.DooTopAM.Header, créez une ligne pour 'Commande Client Créée' en utilisant CreationDate et une autre pour 'Commande Fermée' en utilisant ClosedDate.
- Mapper les codes de statut ou les indicateurs à des activités spécifiques comme 'Commande Confirmée' ou 'Commande Annulée'.
- Combiner toutes les données transformées en un seul fichier avec les colonnes requises : SalesOrder, (ActivityName), et (EventTime).
- Format pour le téléchargement: Assurez-vous que le fichier transformé final est un seul fichier CSV, avec des colonnes correspondant aux attributs requis et recommandés. Le fichier est maintenant prêt à être téléchargé sur ProcessMind.
Configuration
- Sélection des PVO (Public View Objects): La précision du journal d'événements dépend entièrement de la sélection des PVO appropriés. Les PVO clés incluent FscmTopModelAM.DooTopAM.Header (pour la création, 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
LastUpdateDatepour les extractions récurrentes. C'est indispensable pour la performance et pour éviter d'extraire à plusieurs reprises le même jeu de données de plusieurs gigaoctets. Le chargement initial complet doit établir une base de référence, les exécutions ultérieures ne capturant que les modifications. - Plage de Dates: Pour le premier chargement historique, extrayez une période représentative, comme les 3 à 6 derniers mois de données, afin d'équilibrer l'exhaustivité et un volume de données gérable. Les exécutions ultérieures seront incrémentielles.
- Configuration du Stockage: BICC peut exporter vers l'UCM d'Oracle ou vers OCI Object Storage. L'utilisation d'OCI Object Storage est généralement recommandée pour les scénarios de données massives et une intégration plus facile avec les outils ETL en aval.
- Planification des Tâches: Planifiez les tâches d'extraction en dehors des heures ouvrables pour éviter toute dégradation potentielle des performances sur le système transactionnel Oracle Fusion Financials.
- Prérequis: Les utilisateurs configurant la tâche nécessitent le rôle
BICC_ADMINISTRATOR. Vous devez disposer d'identifiants de stockage cloud préconfigurés et d'une compréhension claire de la logique de transformation des données requise 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 filtering