> Amélioration Continue des Processusus > De la commande au paiement Facturation et encaissement > Oracle E Business Suite > Template de données

Votre modèle de données `Order-to-Cash` - Facturation

Oracle E-Business Suite

← Retour au Guide d'amélioration

Attributs De la commande au paiement - Facturation et encaissement (20) Activités De la commande au paiement - Facturation et encaissement (13) Guides d'extraction (3)

Votre modèle de données `Order-to-Cash` - Facturation

Ce modèle fournit les étapes nécessaires à la collecte des données essentielles requises pour analyser votre processus « De la commande au paiement » à l'encaissement - Facturation et Recouvrement. Il décrit les champs de données clés à inclure dans votre Journal d'événements, les étapes de processus critiques à suivre et des conseils pratiques sur l'extraction de ces informations. Utilisez cette ressource pour vous assurer de collecter toutes les données nécessaires à une analyse et une optimisation efficaces des processus.

Attributs recommandés à collecter
Activités clés à suivre
Conseils d'extraction pour Oracle E-Business Suite

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs De la commande au paiement - Facturation et encaissement

Ce sont les champs de données recommandés à inclure dans votre Journal d'événements pour une analyse complète du processus « De la commande au paiement » à l'encaissement - Facturation et Recouvrement.

3 Obligatoire 6 Recommandé 11 Facultatif

	Nom	Descriptionn
	Heure de l'événement EventTime	La date et l'heure exactes de l'activité.
Descriptionn Event Time est l'horodatage associé à chaque activité, fournissant l'ordre chronologique des événements au sein d'un cas. Il s'agit des données brutes utilisées pour toutes les analyses temporelles en Process Mining. Cet attribut est indispensable pour le calcul des indicateurs clés de performance comme les temps de cycle, les durées entre les activités et les délais de processus. Par exemple, la différence d'Event Time entre 'Facture Générée' et 'Facture Approuvée' donne la durée d'approbation. Des horodatages précis et complets sont essentiels à une analyse de processus fiable. Pourquoi est-ce important ? : Il fournit le contexte temporel de chaque événement, rendant possible le calcul des durées, l'analyse des performances du processus et la découverte des points de blocage. Source des données : Provient de divers champs de date des tables Oracle EBS, tels que les champs CREATION_DATE ou LAST_UPDATE_DATE dans des tables comme RA_CUSTOMER_TRX_ALL et AR_CASH_RECEIPTS_ALL. Exemples 2023-04-15T10:00:00Z2023-04-20T14:35:10Z2023-05-15T00:00:00Z
	Numéro de facture InvoiceNumber	L'identifiant unique pour chaque document de facture, servant d'ID de cas principal pour le processus de facturation.
Descriptionn Le Numéro de Facture est la base de l'analyse de facturation : de la commande au paiement, identifiant de manière unique chaque transaction de facturation. Il regroupe toutes les activités connexes, telles que la génération, l'approbation, l'envoi, le paiement et la clôture, en une seule instance de processus cohérente. Cela permet une vision globale complet du cycle de vie de la facture. En Process Mining, l'analyse des processus par Numéro de Facture aide à mesurer le temps de cycle total, à identifier les variantes dans la gestion des factures et à repérer les points de blocage qui retardent le paiement. C'est indispensable pour suivre les factures individuelles tout au long de leur parcours, de la création au règlement. Pourquoi est-ce important ? : C'est l'identifiant de cas clé qui relie tous les événements connexes, permettant la reconstruction et l'analyse de l'ensemble du processus de facturation pour chaque facture unique. Source des données : Ceci est généralement le numéro de transaction de la table RA_CUSTOMER_TRX_ALL dans Oracle Receivables. Exemples INV-9234501788144US-2023-001293
	Nom de l'activité ActivityName	Le nom de l'événement commercial spécifique qui s'est produit à un moment donné du cycle de vie de la facture.
Descriptionn Le nom de l'activité décrit une étape ou un jalon dans le processus de facturation, tel que 'Facture Générée', 'Facture Approuvée' ou 'Paiement Client Reçu'. Une séquence chronologique de ces activités pour un Numéro de facture donné forme le flux de processus. Cet attribut est indispensable pour le Process Mining, car il est utilisé pour construire la cartographie des processus, analyser les variantes de processus et identifier les écarts ou les boucles de reprise. La clarté et la cohérence des noms d'activité sont essentielles pour une analyse significative, comme le calcul du temps entre des étapes spécifiques ou la compréhension de la conformité des processus. Pourquoi est-ce important ? : Cet attribut sert de base à la découverte et de la visualisation du flux de processus, permettant l'analyse des variantes de processus, des points de blocage et du reprises. Source des données : Ceci est généralement dérivé en mappant les changements de statut, les types d'événements ou les événements de création/mise à jour d'enregistrements à partir de diverses tables Oracle EBS (par exemple, AR_PAYMENT_SCHEDULES_ALL, RA_CUSTOMER_TRX_ALL) à des noms d'activité standardisés. Exemples Facture généréeFacture approuvéeDate d'Échéance de Paiement AtteintePaiement client reçu
	Date d'échéance DueDate	La date à laquelle le client est censé payer la facture.
Descriptionn La Date d'échéance est un attribut de date critique qui définit la date limite de paiement d'une facture, telle que déterminée par les conditions de paiement. C'est la référence par rapport à laquelle la performance de paiement réelle est mesurée. Cet attribut est indispensable pour le calcul de KPIs comme le Taux de paiement dans les délais et pour la création de rapports d'ancienneté des factures. En Process Mining, il permet d'analyser les comportements de paiement, comme l'identification des clients qui paient systématiquement en retard ou l'identification de l'impact des retards de processus sur la capacité à collecter les paiements à temps. Pourquoi est-ce important ? : C'est la base pour mesurer la performance des paiements, calculer le vieillissement des factures et évaluer le risque de retards de paiement ou de créances irrécouvrables. Source des données : Disponible dans la table AR_PAYMENT_SCHEDULES_ALL, dans la colonne DUE_DATE. Exemples 2023-05-152023-06-302023-07-01
	Département Department	Le département ou l'équipe fonctionnelle associé à l'utilisateur qui a effectué l'activité.
Descriptionn L'attribut Département fournit un contexte organisationnel pour l'utilisateur qui a effectué une activité, telle que 'Comptes Clients' ou 'Opérations Commerciales'. Cela permet d'agréger l'analyse au niveau de l'équipe ou du département. C'est impératif pour comprendre comment les différentes parties de l'organisation interagissent et influencent le processus de facturation. Cela peut aider à identifier les problèmes systémiques au sein d'un département, à comparer les performances entre les équipes et à analyser l'allocation des ressources. Par exemple, cela permet de ventiler le tableau de bord 'Temps de cycle d'approbation des factures' par département. Pourquoi est-ce important ? : Permet l'analyse des performances du processus par structure organisationnelle, mettant en évidence les différences entre les équipes et aidant à localiser les points de blocage spécifiques à un département. Source des données : Généralement dérivé en joignant les informations utilisateur aux données de la hiérarchie RH de l'organisation, souvent à partir de PER_ALL_ASSIGNMENTS_F ou d'une table RH similaire. Exemples Comptes ClientsOpérations financièresServices de facturation
	ID client CustomerId	Un identifiant unique pour le client à qui la facture a été émise.
Descriptionn L'ID Client lie une facture à un compte client spécifique dans les données de référence. Cela permet l'agrégation et la comparaison des performances de processus entre différents clients. En utilisant cet attribut, les analystes peuvent créer des dashboards qui mettent en évidence les comportements de paiement des clients, identifier quels clients sont associés au plus grand nombre de litiges ou de reprises, et comparer les temps de traitement des factures entre les segments de clientèle. C'est indispensable pour passer d'une vue axée uniquement sur les processus à une analyse orientée client. Pourquoi est-ce important ? : Permet une analyse orientée client, aidant à identifier les schémas de paiement, les litiges fréquents ou les variations de processus spécifiques à certains clients. Source des données : Trouvé dans la table RA_CUSTOMER_TRX_ALL comme SOLD_TO_CUSTOMER_ID ou BILL_TO_CUSTOMER_ID. Exemples CUST-100239845ACME-US-01
	Montant Total de la Facture TotalInvoiceAmount	La valeur monétaire totale de la facture, incluant toutes les lignes d'articles, taxes et frais.
Descriptionn Cet attribut représente la valeur financière totale de la facture envoyée au client. C'est une métrique clée pour l'analyse financière au sein du processus de facturation. En Process Mining, le Montant Total de la Facture est utilisé pour segmenter et filtrer les cas. Par exemple, les analystes peuvent comparer le flux de processus pour les factures de grande valeur par rapport aux factures de faible valeur pour voir si elles sont traitées différemment. Il est également essentiel pour l'analyse d'impact financier, comme le calcul de la valeur des factures bloquées en phase d'approbation. Pourquoi est-ce important ? : Permet une analyse d'impact financier, permettant aux utilisateurs de prioriser les problèmes en fonction de leur valeur monétaire et de comprendre comment différentes valeurs de facture affectent le processus. Source des données : Probablement extrait de la table AR_PAYMENT_SCHEDULES_ALL (AMOUNT_DUE_ORIGINAL) ou calculé à partir de RA_CUSTOMER_TRX_LINES_ALL pour une facture donnée. Exemples 1500.0012550.75500.50
	Statut de la facture InvoiceStatus	Le statut actuel de la facture dans son cycle de vie.
Descriptionn Le statut de la facture reflète l'état actuel d'une facture, tel que 'Ouverte', 'Fermée' ou 'Contestée'. Cela offre une vue d'ensemble de la progression de la facture. Cet attribut est indispensable pour créer des dashboards comme 'Vue d'ensemble du vieillissement et du statut des factures', permettant aux utilisateurs de voir rapidement le volume et la valeur des factures dans différents états. Il aide à prioriser les efforts de recouvrement sur les factures ouvertes et fournit un vue d'ensemble de la santé globale du portefeuille des comptes clients. Pourquoi est-ce important ? : Fournit une vue de l'état actuel des factures, essentielle pour les dashboards opérationnels, la gestion des charges de travail et la priorisation des activités de recouvrement. Source des données : Disponible dans la table AR_PAYMENT_SCHEDULES_ALL, dans la colonne STATUS ('OP' pour ouverte, 'CL' pour fermée). Exemples OuvertClôturéEn litige
	Utilisateur User	L'identifiant de l'utilisateur ayant réalisé l'activité.
Descriptionn Cet attribut identifie l'employé ou l'utilisateur système spécifique responsable de l'exécution d'une étape de processus, comme l'approbation d'une facture ou l'application des encaissements. Il est indispensable pour comprendre l'élément humain du processus. L'analyse par Utilisateur aide à identifier les opportunités de formation, les déséquilibres de répartition de la charge de travail et les différences de performance individuelles. Par exemple, elle peut mettre en évidence quels utilisateurs sont associés au plus grand nombre de reprises ou aux délais d'approbation les plus longs, soutenant ainsi les efforts d'amélioration ciblée des processus. Pourquoi est-ce important ? : Permet une analyse des performances au niveau individuel, aidant à identifier les utilisateurs performants, les besoins en formation et les déséquilibres potentiels de charge de travail. Source des données : Provient des champs d'ID utilisateur comme CREATED_BY ou LAST_UPDATED_BY dans diverses tables de transaction. Cet ID est ensuite joint à FND_USER pour obtenir le nom de l'utilisateur. Exemples JSMITHBWILLIAMSCDAVIS
	Conditions de paiement PaymentTerms	Les modalités convenues qui dictent le moment où un client doit payer sa facture.
Descriptionn Les Conditions de paiement définissent les modalités de règlement, telles que 'Net 30' ou 'Net 60', utilisées pour calculer la Date d'échéance des factures. Elles constituent une donnée de référence essentielle qui a un impact direct sur les flux de trésorerie. L'analyse par Conditions de paiement permet de comprendre comment différents termes affectent le comportement de paiement et le DSO (Days Sales Outstanding). Elle peut révéler si les clients avec des délais de paiement plus courts règlent plus rapidement et guider les décisions stratégiques concernant les conditions de paiement à offrir aux différents segments de clientèle. Pourquoi est-ce important ? : Influence directement la date d'échéance des factures et les prévisions de trésorerie. L'analyser aide à évaluer l'efficacité des différentes politiques de crédit. Source des données : Provient de la table RA_TERMS_B, liée via le TERM_ID dans la table RA_CUSTOMER_TRX_ALL. Exemples Net 30Net 60Dû à la réception
	Dernière mise à jour des données LastDataUpdate	L'horodatage indiquant la dernière actualisation ou extraction des données de cet événement depuis le système source.
Descriptionn Cet attribut fournit l'horodatage de la dernière extraction de données. Il est impératif pour comprendre la la réactualisation des données analysées. Les utilisateurs se fient à ce champ pour savoir si les dashboards et les analyses reflètent l'état le plus actuel du processus. Il aide à gérer les attentes concernant la latence des données et constitue un élément clé des métadonnées pour tout modèle de données fiable. Pourquoi est-ce important ? : Informe les utilisateurs sur la pertinence des données, s'assurant qu'ils comprennent à quel point l'analyse du processus est actuelle. Source des données : C'est un champ de métadonnées généré et horodaté sur chaque enregistrement pendant le processus d'extraction, de transformation et de chargement des données (ETL). Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Devise Currency	Le code de devise pour les montants monétaires de la facture.
Descriptionn Cet attribut spécifie la devise, telle que USD ou EUR, dans laquelle les montants des factures sont libellés. Il fournit le contexte nécessaire à toutes les métriques financières. Lors de l'analyse de données provenant d'opérations multinationales, l'attribut Devise est indispensable pour interpréter et comparer correctement les valeurs financières. Les dashboards peuvent l'utiliser pour filtrer par devise ou pour appliquer des taux de change pour des rapports consolidés. Pourquoi est-ce important ? : Fournit un contexte essentiel pour tous les attributs financiers, garantissant une interprétation et une analyse précises dans un environnement multi-devises. Source des données : Généralement disponible dans la table RA_CUSTOMER_TRX_ALL, dans la colonne INVOICE_CURRENCY_CODE. Exemples USDEURGBP
	Est un reprises IsRework	Un indicateur calculé indiquant si la facture a subi une activité de reprises, telle qu'une modification ou une nouvelle approbation.
Descriptionn Cet indicateur booléen est défini sur vrai si le flux de processus d'une facture contient des activités qui indiquent un reprises, telles que 'Facture Modifiée' ou un second événement 'Facture Approuvée'. Il aide à identifier rapidement les factures qui s'écartent du chemin standard et efficace. Cet attribut est impératif pour des KPIs comme le 'Taux d'erreur de facturation' et le 'Taux de reprises manuel'. Il permet aux analystes de quantifier facilement la fréquence du reprises, de filtrer ces cas inefficaces et d'enquêter sur les causes profondes, telles que les utilisateurs ou les départements les plus associés aux activités de reprises. Pourquoi est-ce important ? : Quantifie l'inefficacité des processus en signalant les factures qui ont nécessité des étapes supplémentaires non standard, permettant l'analyse des causes et de l'impact du reprises. Source des données : Calculé lors de la transformation des données en détectant des séquences d'activités spécifiques (par exemple, 'Facture approuvée' suivie de 'Facture modifiée') au sein d'un cas. Exemples truefaux
	Jours de Vente en Suspens (DSO) DaysSalesOutstanding	Le nombre de jours entre la génération de la facture et la réception du paiement.
Descriptionn Le Days Sales Outstanding (DSO) est une métrique financière critique qui mesure le temps moyen nécessaire pour collecter un paiement après l'émission d'une facture. Cet attribut est calculé pour chaque facture individuelle. Bien que l'indicateur clé de performance (KPI) global soit une moyenne, avoir cette valeur par facture permet une analyse puissante. Il peut être utilisé pour créer des distributions, identifier les valeurs aberrantes et analyser les tendances d'efficacité de recouvrement au fil du temps. Le tableau de bord 'Tendance DSO' visualise directement la moyenne de cet attribut au fil du temps. Pourquoi est-ce important ? : Mesure l'efficacité de recouvrement au niveau de chaque facture individuelle, fournissant les données brutes pour l'analyse des tendances et identifiant les facteurs corrélés à un DSO élevé. Source des données : Calculé lors de la transformation des données. Logique: Horodatage('Customer Payment Received') - Horodatage('Invoice Generated'). Exemples 304592
	Nom du client CustomerName	Le nom légal du client à qui la facture a été émise.
Descriptionn Le Nom du Client fournit un identifiant lisible pour le client. Tandis que l'ID Client est utilisé pour les jointures et l'identification unique, le nom est utilisé pour l'affichage dans les rapports et les dashboards. Cela rend l'analyse plus intuitive, car les utilisateurs peuvent facilement reconnaître les noms de clients au lieu de devoir rechercher des ID. C'est impératif pour créer des visualisations conviviales, comme un graphique à barres montrant le délai de paiement moyen par client. Pourquoi est-ce important ? : Améliore l'utilisabilité des dashboards et des rapports en fournissant un nom compréhensible par l'utilisateur pour le filtrage et le regroupement, rendant l'analyse plus accessible. Source des données : Joint à partir des tables HZ_PARTIES et HZ_CUST_ACCOUNTS en utilisant l'ID client de l'en-tête de facture. Exemples Global Corp Inc.Innovate Solutions Ltd.Test Company LLC
	Numéro de commande de vente SalesOrderNumber	L'identifiant de la commande client originale qui a mené à la création de la facture.
Descriptionn Le Numéro de Commande Client offre un lien direct avec la partie précédente de la gestion des commandes du cycle De la commande au paiement. Il connecte le processus de facturation à la commande client initiale. Cet attribut permet une analyse plus large et inter-processus. Par exemple, les analystes peuvent déterminer si certains types de commandes clients entraînent systématiquement des litiges de facturation ou des retards de paiement. Il fournit un contexte précieux souvent perdu lorsque le processus de facturation est examiné de manière isolée. Pourquoi est-ce important ? : Connecte le processus de facturation au processus de vente en amont, permettant une analyse Order-to-Cash plus holistique et une recherche des causes profondes. Source des données : Généralement disponible dans un champ d'attribut de référence ou d'interface sur la table de ligne de facture, RA_CUSTOMER_TRX_LINES_ALL, tel que INTERFACE_LINE_ATTRIBUTE1 ou un flexfield descriptif similaire. Exemples SO-54321601882ORD-2023-9910
	Paiement à temps IsPaidOnTime	Un indicateur calculé qui indique si la facture a été payée à ou avant sa date d'échéance.
Descriptionn C'est un attribut booléen dérivé en comparant l'horodatage « Paiement Client Reçu » avec la « Date d'échéance » de la facture. Il est vrai si le paiement a été effectué à temps ou en avance, et faux s'il a été en retard. Cet indicateur simplifie la création de KPIs et de dashboards liés à la performance de paiement. Il est l'entrée directe pour le calcul du KPI « Taux de paiement dans les délais » et permet un filtrage et une segmentation faciles des factures en catégories « à temps » et « en retard » pour une analyse plus approfondie des causes profondes. Pourquoi est-ce important ? : Facilite le KPI 'Taux de paiement ponctuel' « what-if »mplifie les analyses en catégorisant les factures en groupes 'à temps' et 'en retard'. Source des données : Calculé lors de la transformation des données. Logique: IF (Horodatage('Customer Payment Received') <= Date('DueDate')) THEN true ELSE false. Exemples truefaux
	Pays du client Country	Le pays de l'adresse de facturation du client.
Descriptionn Cet attribut spécifie le pays associé à l'adresse de facturation du client. Il fournit une dimension géographique pour l'analyse des processus. L'analyse du processus par pays peut révéler des différences régionales dans les comportements de paiement, l'efficacité des processus ou la conformité aux réglementations locales. Par exemple, il peut être utilisé dans le tableau de bord 'Insights sur le comportement de paiement des clients' pour voir si les retards de paiement moyens diffèrent significativement entre les pays. Pourquoi est-ce important ? : Permet une analyse géographique du processus, mettant en évidence les variations régionales dans le comportement des clients, l'impact réglementaire ou les performances opérationnelles. Source des données : Joint à partir des informations de l'adresse de facturation du client stockées dans HZ_LOCATIONS et FND_TERRITORIES, liées via les tables de comptes clients. Exemples États-UnisAllemagneRoyaume-Uni
	Système source SourceSystem	Le système d'enregistrement à partir duquel les données ont été extraites.
Descriptionn Cet attribut identifie l'application source d'où proviennent les données de l'événement. Pour ce processus, il s'agira systématiquement d'Oracle E-Business Suite. Dans les environnements multi-systèmes, ce champ est indispensable pour la traçabilité des données et le dépannage. Même dans un contexte de système unique, c'est un champ obligatoire pour la gouvernance des données, confirmant que les données proviennent de la source attendue. Pourquoi est-ce important ? : Assure la traçabilité et le contexte des données, ce qui est impératif pour la gouvernance des données et lors de l'intégration de données provenant de plusieurs systèmes d'entreprise. Source des données : C'est une valeur statique définie pendant le processus d'extraction des données pour identifier l'ERP source. Exemples Oracle E-Business SuiteOracle EBS R12
	Unité commerciale BusinessUnit	L'unité commerciale ou l'unité opérationnelle spécifique dans l'entreprise qui a émis la facture.
Descriptionn L'Unité commerciale représente l'entité organisationnelle responsable de la transaction. Dans Oracle EBS, elle est souvent représentée par l'Unité Opérationnelle. Cet attribut permet de comparer la performance des processus entre différentes parties de l'entreprise. Il peut aider à déterminer si certaines unités commerciales sont plus efficaces, ont des taux de paiement dans les délais plus élevés ou rencontrent davantage de litiges, favorisant le partage des meilleures pratiques et les interventions ciblées. Pourquoi est-ce important ? : Permet la comparaison des performances entre différentes parties de l'organisation, aidant à identifier les meilleures pratiques et les défis spécifiques à chaque domaine. Source des données : Le contexte de l'unité opérationnelle est implicitement disponible via l'ORG_ID sur la plupart des tables de transaction comme RA_CUSTOMER_TRX_ALL. Exemples Opérations AméricainesServices EMEAFabrication mondiale

Obligatoire Recommandé Facultatif

Activités De la commande au paiement - Facturation et encaissement

Ce sont les étapes de processus et les jalons essentiels à capturer dans votre Journal d'événements pour une découverte et une analyse précises de vos opérations de facturation.

5 Recommandé 8 Facultatif

	Activité	Descriptionn
	Facture clôturée	La facture est officiellement clôturée, signifiant que son solde est nul en raison de paiements, d'avoirs et/ou d'ajustements. Cela marque l'achèvement réussi du cycle de vie de la facture.
Pourquoi est-ce important ? : C'est le point final principal du processus. Le temps de cycle total de « Facture Générée » à « Facture Clôturée » est un indicateur clé de l'efficacité globale du cycle de facturation : de la commande au paiement. Source des données : Déduit du champ STATUS dans la table AR_PAYMENT_SCHEDULES_ALL passant à 'CL' (Fermée). La date de la transaction finale ayant entraîné la clôture peut être utilisée comme horodatage. Capture Déduit du statut passant à 'CL' dans AR_PAYMENT_SCHEDULES_ALL, horodaté par la dernière application associée. Type d'événement inferred
	Facture envoyée au client	Cette activité signifie que la facture a été officiellement transmise au client, soit par impression, soit par voie électronique. Cet événement marque le début du décompte des délais de paiement du client.
Pourquoi est-ce important ? : C'est un jalon clé pour mesurer le délai de livraison des factures et le décalage jusqu'au paiement. Il aide à distinguer les retards de traitement internes du comportement de paiement des clients. Source des données : Oracle EBS n'enregistre pas toujours explicitement cet événement dans un champ standard. Il peut être déduit de l'horodatage du programme concurrent 'Impression de facture' ou d'un indicateur personnalisé défini lors de la livraison électronique. Capture Déduit de la date d'achèvement du programme d'impression de factures ou de la logique personnalisée pour la transmission électronique. Type d'événement inferred
	Facture générée	Marque la création d'une nouvelle transaction de facture dans le système. Cet événement est généralement déclenché par le 'Programme d'Importation Autofacturation' qui traite les lignes de commandes clients exécutées, ou par la saisie manuelle de factures dans le module Comptes Clients.
Pourquoi est-ce important ? : C'est le point de départ du processus de facturation. L'analyse du temps écoulé entre cet événement et les autres révèle le cycle de vie total de la facture et aide à identifier les points de blocage précoces. Source des données : Comptabilisé comme la date de création d'une transaction dans la table Oracle Receivables RA_CUSTOMER_TRX_ALL. Le champ TRX_DATE ou CREATION_DATE peut être utilisé comme horodatage de l'événement. Capture L'événement est l'horodatage de création d'un enregistrement dans la table RA_CUSTOMER_TRX_ALL. Type d'événement explicit
	Paiement Appliqué/Rapproché	Le paiement client reçu a été appliqué avec succès à une ou plusieurs factures spécifiques, réduisant le solde dû. Cela représente le rapprochement du paiement par rapport à la dette.
Pourquoi est-ce important ? : C'est la dernière étape du processus de paiement et elle est indispensable pour mesurer le temps de cycle d'application des encaissements. Les retards ici peuvent fausser les soldes des comptes clients et affecter la gestion du crédit. Source des données : Cet événement est explicitement enregistré avec un horodatage lorsqu'un enregistrement est créé dans la table AR_RECEIVABLE_APPLICATIONS_ALL liant un encaissement à une transaction. Capture L'événement est l'horodatage de création (GL_DATE ou APPLY_DATE) d'un enregistrement dans AR_RECEIVABLE_APPLICATIONS_ALL. Type d'événement explicit
	Paiement client reçu	Un paiement d'un client a été enregistré dans le système comme un encaissement. À ce stade, le paiement peut ne pas encore être appliqué à une facture spécifique.
Pourquoi est-ce important ? : C'est un jalon majeur pour le calcul du DSO (Days Sales Outstanding). Le temps entre la génération de la facture et la réception du paiement est une mesure principale de l'efficacité du recouvrement. Source des données : Cet événement est explicitement enregistré avec un horodatage lors de la création d'un enregistrement dans la table AR_CASH_RECEIPTS_ALL. Capture L'événement est l'horodatage de création d'un enregistrement dans la table AR_CASH_RECEIPTS_ALL. Type d'événement explicit
	Avoir émis	Une transaction de note de crédit est générée et souvent appliquée à une facture existante pour corriger une erreur de facturation ou traiter un retour. Il s'agit d'une transaction distincte mais liée danss Comptes Clients.
Pourquoi est-ce important ? : Des volumes élevés de notes de crédit indiquent des problèmes en amont dans l'exécution des commandes, la tarification ou l'exactitude initiale de la facturation. L'analyse de ces événements est indispensablele à l'analyse des causes profondes des fuites de revenus et de l'insatisfaction client. Source des données : Comptabilisé comme une nouvelle transaction dans RA_CUSTOMER_TRX_ALL où le CUST_TRX_TYPE_ID est lié à un type de classe 'CM' (Avoir). Le champ PREVIOUS_CUSTOMER_TRX_ID le relie à la facture originale. Capture L'événement est la création d'un enregistrement dans RA_CUSTOMER_TRX_ALL avec un type de transaction de note de crédit. Type d'événement explicit
	Date d'Échéance de Paiement Atteinte	Un événement calculé marquant le jour où la facture devient exigible selon ses conditions de paiement. Cet événement ne correspond pas à une action utilisateur ou système, mais constitue une étape temporelle critique.
Pourquoi est-ce important ? : Cet événement est indispensable pour calculer les taux de paiement dans les délais et analyser le comportement de paiement des clients. Il sert de référence pour déterminer si un paiement est anticipé, dans les délais ou en retard. Source des données : Ceci n'est pas enregistré comme un événement. Il est calculé en comparant la date système au champ TERM_DUE_DATE de la table AR_PAYMENT_SCHEDULES_ALL pour la facture spécifique. Capture Dérivé en comparant l'horodatage actuel avec la colonne TERM_DUE_DATE de la table AR_PAYMENT_SCHEDULES_ALL. Type d'événement calculated
	Facture approuvée	Représente l'approbation interne formelle d'une facture saisie manuellement ou révisée avant son envoi au client. Cette activité peut faire partie d'un Workflow Oracle configuré ou d'un changement de statut manuel.
Pourquoi est-ce important ? : Le suivi du temps d'approbation est indispensable pour le KPI 'Temps de cycle d'approbation des factures'. Les retards ici reportent directement la facturation client et prolongent le cycle global de conversion de trésorerie. Source des données : Ceci dépend souvent de la configuration. Il peut être déduit des changements de statut dans les tables de workflow (par exemple, WF_ITEM_ACTIVITY_STATUSES) ou potentiellement d'un champ descriptif (flexfield) sur la transaction de facture dans RA_CUSTOMER_TRX_ALL. Capture Déduit des changements de statut dans les tables de workflow ou les champs de statut personnalisés. Type d'événement inferred
	Facture Modifiée	Indique qu'une facture existante et incomplète a été mise à jour ou corrigée. Cela pourrait impliquer la modification des postes, des montants ou des informations de facturation avant que la facture ne soit terminée ou envoyée.
Pourquoi est-ce important ? : Les modifications fréquentes suggèrent des inefficacités de processus, des problèmes de qualité des données ou des erreurs d'utilisateur. L'analyse de cette activité aide à quantifier les reprises et son impact sur les temps de cycle, soutenant des KPI comme le 'Taux d'erreur de facturation'. Source des données : Peut être déduit en comparant la CREATION_DATE avec la LAST_UPDATE_DATE sur la table RA_CUSTOMER_TRX_ALL pour les factures incomplètes. Si l'audit est activé, les modifications peuvent être suivies plus explicitement. Capture Déduit en suivant les mises à jour via LAST_UPDATE_DATE sur la table RA_CUSTOMER_TRX_ALL. Type d'événement inferred
	Litige déclaré	Le client a formellement contesté la facture, entraînant une suspension des activités de recouvrement jusqu'à résolution. Cela est souvent géré au sein d'Oracle Advanced Collections ou par des mises à jour de statut manuelles.
Pourquoi est-ce important ? : Les litiges impactent directement la trésorerie en retardant les paiements. Le suivi de leur fréquence et de leur temps de résolution aide à identifier les problèmes récurrents avec les produits, les services ou l'exactitude de la facturation. Source des données : Si Oracle Advanced Collections est utilisé, il s'agit d'une transaction explicite. Autrement, cela peut être déduit d'un statut de 'litige' spécifique ou d'une retenue appliquée à la facture dans les Comptes Clients (AR). Capture Comptabilisé comme une transaction dans Oracle Advanced Collections ou déduit d'un changement de statut sur la facture. Type d'événement explicit
	Paiement Annulé	Indique qu'un paiement client précédemment reçu a été annulé. Cela se produit généralement en raison de fonds insuffisants (NSF) ou d'autres erreurs de traitement bancaire.
Pourquoi est-ce important ? : Les annulations de paiement perturbent les prévisions de flux de trésorerie et exigent un effort administratif supplémentaire. Le suivi de ces événements permet d'identifier les clients ou les méthodes de paiement problématiques. Source des données : C'est une action explicite dans Oracle Receivables. Une annulation crée des entrées dans AR_CASH_RECEIPT_HISTORY_ALL avec un statut indiquant l'annulation, tel que 'REVERSED'. Capture Identifié par un changement de statut à 'REVERSED' dans la table AR_CASH_RECEIPT_HISTORY_ALL. Type d'événement explicit
	Radiation de Créance Créée	Un ajustement est effectué pour passer en perte tout ou partie du solde de la facture restante en tant que créance irrécouvrable. Cela se produit généralement après l'épuisement des efforts de recouvrement.
Pourquoi est-ce important ? : Les radiations de créances représentent une perte directe de revenus. L'analyse de leur fréquence et de leur valeur aide à affiner les politiques de crédit et à comprendre l'impact financier des créances irrécouvrables. Source des données : C'est enregistré comme une transaction de type ajustement spécifique contre la facture. L'événement peut être trouvé dans la table AR_ADJUSTMENTS_ALL avec un lien vers un type d'activité de créance défini pour les radiations. Capture L'événement est la création d'un enregistrement dans AR_ADJUSTMENTS_ALL avec un type d'activité 'Radiation de créance'. Type d'événement explicit
	Rappel de Paiement Émis	Un avis de relance ou de rappel a été envoyé au client concernant une facture en retard. C'est une activité clé dans le processus de recouvrement.
Pourquoi est-ce important ? : Le suivi de cette activité est impératif pour mesurer l'efficacité des stratégies de recouvrement. Il permet d'analyser les taux de paiement avant et après l'envoi des rappels. Source des données : Si Oracle Advanced Collections est utilisé, l'envoi d'une lettre de relance est enregistré comme un événement explicite. Sans ce module, cette activité est souvent réalisée en dehors du système et ne peut pas être suivie de manière fiable. Capture Comptabilisé comme un événement de correspondance de relance dans le module Oracle Advanced Collections. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos `données` d'`Oracle E-Business Suite`

Étapes

Connectez-vous à Oracle E-Business Suite: Accédez à votre instance Oracle EBS avec un utilisateur disposant de la responsabilité 'XML Publisher Administrator' ou similaire, octroyant l'accès à BI Publisher.
Naviguez vers BI Publisher: Depuis le navigateur principal, sélectionnez la responsabilité BI Publisher, puis cliquez sur 'Data Models'.
Créez un nouveau modèle de données: Sur la page Data Model, cliquez sur le bouton 'Create' ou l'icône '+' pour démarrer un nouveau modèle de données.
Définissez l'ensemble de données de la requête SQL: Dans l'éditeur de modèle de données, cliquez sur l'icône '+' et sélectionnez 'SQL Query'. Cela ouvrira le constructeur de requêtes SQL.
Configurez l'ensemble de données: Donnez à votre ensemble de données un nom descriptif, par exemple, 'O2C_INVOICING_EVENT_LOG'. Sélectionnez la 'Source de données' appropriée pour votre base de données EBS, généralement nommée 'EBS' ou similaire.
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 de la requête SQL.
Définissez les paramètres de la requête: La requête utilise des paramètres tels que p_start_date, p_end_date et p_org_id. BI Publisher les détectera automatiquement. Vous pouvez les configurer comme obligatoires et définir leurs types de données (Date pour les dates, Integer pour l'ID) et des valeurs par défaut si vous le souhaitez.
Enregistrez le modèle de données: Après avoir collé la requête et configuré les paramètres, enregistrez le modèle de données avec un nom unique et descriptif, par exemple, 'Extraction Facturation et encaissement O2C'.
Créez un rapport BI Publisher: Naviguez vers le catalogue BI Publisher et créez un nouveau rapport. Sélectionnez le modèle de données que vous venez d'enregistrer.
Configurez le rapport: Suivez l'assistant de création de rapport. Une mise en page simple de type 'tableau' est suffisante. Il n'est pas nécessaire d'utiliser un modèle visuel complexe, car l'objectif est l'exportation de données brutes.
Exécutez et exportez les données: Visualisez le rapport. Lorsque vous y êtes invité, saisissez la date de début, la date de fin et l'ID d'organisation souhaités. Une fois le rapport exécuté, utilisez la fonction 'Export' pour enregistrer la sortie sous forme de fichier CSV.
Préparez le fichier pour le téléchargement: Assurez-vous que le fichier CSV exporté est encodé au format UTF-8. Vérifiez que les en-têtes de colonne correspondent aux exigences de ProcessMind: InvoiceNumber, (ActivityName), (EventTime), etc. Le fichier est maintenant prêt à être téléchargé.

Configuration

Source de données: La requête doit être exécutée sur la source de base de données Oracle E-Business Suite (par exemple, EBS) configurée dans BI Publisher.
Paramètres de plage de dates: La requête inclut p_start_date et p_end_date pour contrôler la période d'extraction. Pour l'analyse initiale, une période de 3 à 6 mois est recommandée pour équilibrer le volume de données et les informations sur le processus.
Filtre organisationnel: Le paramètre p_org_id est impératif pour limiter les données à une unité opérationnelle ou une organisation spécifique. L'exécution de la requête pour toutes les organisations à la fois peut entraîner des temps d'exécution extrêmement longs et des fichiers excessivement volumineux.
Prérequis: L'utilisateur exécutant le rapport a besoin d'un accès en lecture à plusieurs modules clés d'Oracle Financials et de support, y compris les Comptes Clients (AR), Fondation (FND), et potentiellement les Ressources Humaines (PER) pour les détails des utilisateurs. L'accès à la responsabilité BI Publisher est requis pour créer et exécuter le modèle de données et le rapport.
Considérations de performance: Il s'agit d'une requête complète qui joint plusieurs grandes tables. Pour les environnements avec des volumes de transactions très élevés, envisagez d'exécuter l'extraction pendant les heures creuses ou par lots de plages de dates plus petits pour éviter une dégradation des performances du système.

a Exemple de requête sql

WITH base_invoices AS (
  SELECT
    rct.customer_trx_id,
    rct.trx_number,
    rct.trx_date,
    rct.creation_date,
    rct.created_by,
    rct.last_update_date,
    rct.last_updated_by,
    rct.bill_to_customer_id,
    rct.org_id,
    ps.amount_due_original,
    ps.due_date,
    ps.status AS payment_schedule_status,
    ps.class,
    ps.payment_schedule_id
  FROM
    ar.ra_customer_trx_all rct,
    ar.ar_payment_schedules_all ps
  WHERE
    rct.customer_trx_id = ps.customer_trx_id
    AND rct.trx_date BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
    AND rct.org_id = :p_org_id
    AND ps.class = 'INV'
    AND rct.complete_flag = 'Y'
)
-- 1. Invoice Generated
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Generated' AS "ActivityName",
  inv.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department", -- Placeholder for department logic
  'OPEN' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN applsys.fnd_user fu ON inv.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND inv.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
UNION ALL
-- 2. Invoice Approved (using completion as proxy)
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Approved' AS "ActivityName",
  rct.last_update_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'OPEN' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ra_customer_trx_all rct ON inv.customer_trx_id = rct.customer_trx_id
  JOIN applsys.fnd_user fu ON rct.last_updated_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND rct.last_update_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  rct.complete_flag = 'Y' 
  AND rct.initial_customer_trx_id IS NULL -- Only for manually entered or imported invoices, not copies
UNION ALL
-- 3. Invoice Sent To Customer (using first print date)
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Sent To Customer' AS "ActivityName",
  rct.printing_original_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'OPEN' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ra_customer_trx_all rct ON inv.customer_trx_id = rct.customer_trx_id
  JOIN applsys.fnd_user fu ON rct.last_updated_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND rct.printing_original_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  rct.printing_original_date IS NOT NULL
UNION ALL
-- 4. Invoice Modified
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Modified' AS "ActivityName",
  rct.last_update_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'INCOMPLETE' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ra_customer_trx_all rct ON inv.customer_trx_id = rct.customer_trx_id
  JOIN applsys.fnd_user fu ON rct.last_updated_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND rct.last_update_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  rct.last_update_date > rct.creation_date
  AND rct.complete_flag = 'N' -- Capturing modifications while incomplete
UNION ALL
-- 5. Credit Memo Created
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Credit Memo Created' AS "ActivityName",
  cm.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ra_customer_trx_all cm ON inv.customer_trx_id = cm.previous_customer_trx_id
  JOIN applsys.fnd_user fu ON cm.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND cm.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  cm.trx_class = 'CM'
UNION ALL
-- 6. Dispute Raised
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Dispute Raised' AS "ActivityName",
  adj.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'DISPUTED' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_adjustments_all adj ON inv.customer_trx_id = adj.customer_trx_id
  JOIN applsys.fnd_user fu ON adj.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND adj.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  adj.type = 'INVOICE' AND adj.status = 'A' -- Approved adjustments related to disputes
UNION ALL
-- 7. Payment Due Date Reached
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Payment Due Date Reached' AS "ActivityName",
  inv.due_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  'System' AS "User",
  NULL AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
WHERE
  inv.due_date < SYSDATE
UNION ALL
-- 8. Payment Reminder Issued
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Payment Reminder Issued' AS "ActivityName",
  dunning.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  NULL AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN iex.iex_dunnings dunning ON inv.payment_schedule_id = dunning.payment_schedule_id
  JOIN applsys.fnd_user fu ON dunning.created_by = fu.user_id
UNION ALL
-- 9. Customer Payment Received
SELECT DISTINCT
  inv.trx_number AS "InvoiceNumber",
  'Customer Payment Received' AS "ActivityName",
  cr.receipt_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_receivable_applications_all app ON inv.customer_trx_id = app.applied_customer_trx_id
  JOIN ar.ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
  JOIN applsys.fnd_user fu ON cr.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND cr.receipt_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE app.status = 'APP'
UNION ALL
-- 10. Payment Reversed
SELECT DISTINCT
  inv.trx_number AS "InvoiceNumber",
  'Payment Reversed' AS "ActivityName",
  crh.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'OPEN' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_receivable_applications_all app ON inv.customer_trx_id = app.applied_customer_trx_id
  JOIN ar.ar_cash_receipt_history_all crh ON app.cash_receipt_id = crh.cash_receipt_id
  JOIN applsys.fnd_user fu ON crh.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND crh.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  crh.status = 'REVERSED'
UNION ALL
-- 11. Cash Applied/Reconciled
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Cash Applied/Reconciled' AS "ActivityName",
  app.apply_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_receivable_applications_all app ON inv.customer_trx_id = app.applied_customer_trx_id
  JOIN applsys.fnd_user fu ON app.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND app.apply_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  app.status = 'APP'
  AND app.display = 'Y'
UNION ALL
-- 12. Write-Off Created
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Write-Off Created' AS "ActivityName",
  adj.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_adjustments_all adj ON inv.customer_trx_id = adj.customer_trx_id
  JOIN ar.ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
  JOIN applsys.fnd_user fu ON adj.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND adj.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  rt.name LIKE '%Write-Off%'
UNION ALL
-- 13. Invoice Closed
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Closed' AS "ActivityName",
  ps_closed.last_update_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'CLOSED' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_payment_schedules_all ps_closed ON inv.payment_schedule_id = ps_closed.payment_schedule_id
  JOIN applsys.fnd_user fu ON ps_closed.last_updated_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND ps_closed.last_update_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  ps_closed.status = 'CL'

Étapes

Connectez-vous à Oracle E-Business Suite: Accédez à votre instance Oracle EBS avec un utilisateur disposant de la responsabilité 'XML Publisher Administrator' ou similaire, octroyant l'accès à BI Publisher.
Naviguez vers BI Publisher: Depuis le navigateur principal, sélectionnez la responsabilité BI Publisher, puis cliquez sur 'Data Models'.
Créez un nouveau modèle de données: Sur la page Data Model, cliquez sur le bouton 'Create' ou l'icône '+' pour démarrer un nouveau modèle de données.
Définissez l'ensemble de données de la requête SQL: Dans l'éditeur de modèle de données, cliquez sur l'icône '+' et sélectionnez 'SQL Query'. Cela ouvrira le constructeur de requêtes SQL.
Configurez l'ensemble de données: Donnez à votre ensemble de données un nom descriptif, par exemple, 'O2C_INVOICING_EVENT_LOG'. Sélectionnez la 'Source de données' appropriée pour votre base de données EBS, généralement nommée 'EBS' ou similaire.
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 de la requête SQL.
Définissez les paramètres de la requête: La requête utilise des paramètres tels que p_start_date, p_end_date et p_org_id. BI Publisher les détectera automatiquement. Vous pouvez les configurer comme obligatoires et définir leurs types de données (Date pour les dates, Integer pour l'ID) et des valeurs par défaut si vous le souhaitez.
Enregistrez le modèle de données: Après avoir collé la requête et configuré les paramètres, enregistrez le modèle de données avec un nom unique et descriptif, par exemple, 'Extraction Facturation et encaissement O2C'.
Créez un rapport BI Publisher: Naviguez vers le catalogue BI Publisher et créez un nouveau rapport. Sélectionnez le modèle de données que vous venez d'enregistrer.
Configurez le rapport: Suivez l'assistant de création de rapport. Une mise en page simple de type 'tableau' est suffisante. Il n'est pas nécessaire d'utiliser un modèle visuel complexe, car l'objectif est l'exportation de données brutes.
Exécutez et exportez les données: Visualisez le rapport. Lorsque vous y êtes invité, saisissez la date de début, la date de fin et l'ID d'organisation souhaités. Une fois le rapport exécuté, utilisez la fonction 'Export' pour enregistrer la sortie sous forme de fichier CSV.
Préparez le fichier pour le téléchargement: Assurez-vous que le fichier CSV exporté est encodé au format UTF-8. Vérifiez que les en-têtes de colonne correspondent aux exigences de ProcessMind: InvoiceNumber, (ActivityName), (EventTime), etc. Le fichier est maintenant prêt à être téléchargé.

Configuration

Source de données: La requête doit être exécutée sur la source de base de données Oracle E-Business Suite (par exemple, EBS) configurée dans BI Publisher.
Paramètres de plage de dates: La requête inclut p_start_date et p_end_date pour contrôler la période d'extraction. Pour l'analyse initiale, une période de 3 à 6 mois est recommandée pour équilibrer le volume de données et les informations sur le processus.
Filtre organisationnel: Le paramètre p_org_id est impératif pour limiter les données à une unité opérationnelle ou une organisation spécifique. L'exécution de la requête pour toutes les organisations à la fois peut entraîner des temps d'exécution extrêmement longs et des fichiers excessivement volumineux.
Prérequis: L'utilisateur exécutant le rapport a besoin d'un accès en lecture à plusieurs modules clés d'Oracle Financials et de support, y compris les Comptes Clients (AR), Fondation (FND), et potentiellement les Ressources Humaines (PER) pour les détails des utilisateurs. L'accès à la responsabilité BI Publisher est requis pour créer et exécuter le modèle de données et le rapport.
Considérations de performance: Il s'agit d'une requête complète qui joint plusieurs grandes tables. Pour les environnements avec des volumes de transactions très élevés, envisagez d'exécuter l'extraction pendant les heures creuses ou par lots de plages de dates plus petits pour éviter une dégradation des performances du système.

a Exemple de requête sql

WITH base_invoices AS (
  SELECT
    rct.customer_trx_id,
    rct.trx_number,
    rct.trx_date,
    rct.creation_date,
    rct.created_by,
    rct.last_update_date,
    rct.last_updated_by,
    rct.bill_to_customer_id,
    rct.org_id,
    ps.amount_due_original,
    ps.due_date,
    ps.status AS payment_schedule_status,
    ps.class,
    ps.payment_schedule_id
  FROM
    ar.ra_customer_trx_all rct,
    ar.ar_payment_schedules_all ps
  WHERE
    rct.customer_trx_id = ps.customer_trx_id
    AND rct.trx_date BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
    AND rct.org_id = :p_org_id
    AND ps.class = 'INV'
    AND rct.complete_flag = 'Y'
)
-- 1. Invoice Generated
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Generated' AS "ActivityName",
  inv.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department", -- Placeholder for department logic
  'OPEN' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN applsys.fnd_user fu ON inv.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND inv.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
UNION ALL
-- 2. Invoice Approved (using completion as proxy)
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Approved' AS "ActivityName",
  rct.last_update_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'OPEN' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ra_customer_trx_all rct ON inv.customer_trx_id = rct.customer_trx_id
  JOIN applsys.fnd_user fu ON rct.last_updated_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND rct.last_update_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  rct.complete_flag = 'Y' 
  AND rct.initial_customer_trx_id IS NULL -- Only for manually entered or imported invoices, not copies
UNION ALL
-- 3. Invoice Sent To Customer (using first print date)
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Sent To Customer' AS "ActivityName",
  rct.printing_original_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'OPEN' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ra_customer_trx_all rct ON inv.customer_trx_id = rct.customer_trx_id
  JOIN applsys.fnd_user fu ON rct.last_updated_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND rct.printing_original_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  rct.printing_original_date IS NOT NULL
UNION ALL
-- 4. Invoice Modified
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Modified' AS "ActivityName",
  rct.last_update_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'INCOMPLETE' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ra_customer_trx_all rct ON inv.customer_trx_id = rct.customer_trx_id
  JOIN applsys.fnd_user fu ON rct.last_updated_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND rct.last_update_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  rct.last_update_date > rct.creation_date
  AND rct.complete_flag = 'N' -- Capturing modifications while incomplete
UNION ALL
-- 5. Credit Memo Created
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Credit Memo Created' AS "ActivityName",
  cm.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ra_customer_trx_all cm ON inv.customer_trx_id = cm.previous_customer_trx_id
  JOIN applsys.fnd_user fu ON cm.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND cm.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  cm.trx_class = 'CM'
UNION ALL
-- 6. Dispute Raised
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Dispute Raised' AS "ActivityName",
  adj.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'DISPUTED' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_adjustments_all adj ON inv.customer_trx_id = adj.customer_trx_id
  JOIN applsys.fnd_user fu ON adj.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND adj.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  adj.type = 'INVOICE' AND adj.status = 'A' -- Approved adjustments related to disputes
UNION ALL
-- 7. Payment Due Date Reached
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Payment Due Date Reached' AS "ActivityName",
  inv.due_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  'System' AS "User",
  NULL AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
WHERE
  inv.due_date < SYSDATE
UNION ALL
-- 8. Payment Reminder Issued
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Payment Reminder Issued' AS "ActivityName",
  dunning.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  NULL AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN iex.iex_dunnings dunning ON inv.payment_schedule_id = dunning.payment_schedule_id
  JOIN applsys.fnd_user fu ON dunning.created_by = fu.user_id
UNION ALL
-- 9. Customer Payment Received
SELECT DISTINCT
  inv.trx_number AS "InvoiceNumber",
  'Customer Payment Received' AS "ActivityName",
  cr.receipt_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_receivable_applications_all app ON inv.customer_trx_id = app.applied_customer_trx_id
  JOIN ar.ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
  JOIN applsys.fnd_user fu ON cr.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND cr.receipt_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE app.status = 'APP'
UNION ALL
-- 10. Payment Reversed
SELECT DISTINCT
  inv.trx_number AS "InvoiceNumber",
  'Payment Reversed' AS "ActivityName",
  crh.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'OPEN' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_receivable_applications_all app ON inv.customer_trx_id = app.applied_customer_trx_id
  JOIN ar.ar_cash_receipt_history_all crh ON app.cash_receipt_id = crh.cash_receipt_id
  JOIN applsys.fnd_user fu ON crh.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND crh.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  crh.status = 'REVERSED'
UNION ALL
-- 11. Cash Applied/Reconciled
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Cash Applied/Reconciled' AS "ActivityName",
  app.apply_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_receivable_applications_all app ON inv.customer_trx_id = app.applied_customer_trx_id
  JOIN applsys.fnd_user fu ON app.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND app.apply_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  app.status = 'APP'
  AND app.display = 'Y'
UNION ALL
-- 12. Write-Off Created
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Write-Off Created' AS "ActivityName",
  adj.creation_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  inv.payment_schedule_status AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_adjustments_all adj ON inv.customer_trx_id = adj.customer_trx_id
  JOIN ar.ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
  JOIN applsys.fnd_user fu ON adj.created_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND adj.creation_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  rt.name LIKE '%Write-Off%'
UNION ALL
-- 13. Invoice Closed
SELECT
  inv.trx_number AS "InvoiceNumber",
  'Invoice Closed' AS "ActivityName",
  ps_closed.last_update_date AS "EventTime",
  inv.amount_due_original AS "TotalInvoiceAmount",
  inv.due_date AS "DueDate",
  inv.bill_to_customer_id AS "CustomerId",
  fu.user_name AS "User",
  papf.full_name AS "Department",
  'CLOSED' AS "InvoiceStatus"
FROM
  base_invoices inv
  JOIN ar.ar_payment_schedules_all ps_closed ON inv.payment_schedule_id = ps_closed.payment_schedule_id
  JOIN applsys.fnd_user fu ON ps_closed.last_updated_by = fu.user_id
  LEFT JOIN applsys.per_all_people_f papf ON fu.employee_id = papf.person_id AND ps_closed.last_update_date BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
  ps_closed.status = 'CL'

Étapes

Configurez l'environnement Python: Assurez-vous d'avoir Python 3.6 ou une version plus récente installée sur votre machine. Installez les bibliothèques nécessaires, pandas et oracledb, à l'aide de pip: pip install pandas oracledb
Préparez le script Python: Créez un nouveau fichier Python (par exemple, extract_invoices.py) et copiez le script complet fourni dans la section query dans ce fichier.
Configurez la connexion à la base de données: Dans le script, localisez la section des détails de connexion. Remplacez les valeurs de substitution pour user, password et dsn par vos identifiants et chaîne de connexion réels de votre base de données Oracle E-Business Suite. Le DSN, ou Data Source Name, suit généralement le format hostname:port/service_name.
Définissez les paramètres d'extraction: Modifiez le dictionnaire params dans le script. Définissez les placeholders :start_date, :end_date et :org_id pour définir la portée de votre extraction de données. Utilisez le format 'YYYY-MM-DD' pour les dates.
Exécutez le script: Exécutez le script depuis votre terminal en utilisant la commande: python extract_invoices.py Le script se connectera à la base de données, exécutera la requête SQL et récupérera les résultats.
Récupérez le journal d'événements: Une fois le script terminé, un fichier nommé oracle_ebs_billing_event_log.csv sera créé dans le même répertoire. Ce fichier contient le journal d'événements extrait.
Examinez les données: Ouvrez le fichier CSV dans une application de feuille de calcul pour vérifier son contenu. Vérifiez que toutes les colonnes attendues sont présentes et que les données pour les activités, les horodatages et les attributs semblent correctes.
Préparez pour le téléchargement: Le fichier CSV généré est formaté pour une utilisation directe. Assurez-vous que les en-têtes de colonne correspondent aux champs case_id, activity et horodatage requis pour votre outil de process mining. Le script les nomme respectivement InvoiceNumber, (ActivityName) et (EventTime).

Configuration

Identifiants de base de données: Un utilisateur de base de données avec un accès en lecture seule aux schémas Oracle E-Business Suite est requis. Plus précisément, l'utilisateur a besoin des autorisations nécessaires pour interroger des tables comme RA_CUSTOMER_TRX_ALL, AR_PAYMENT_SCHEDULES_ALL, AR_CASH_RECEIPTS_ALL, AR_RECEIVABLE_APPLICATIONS_ALL, AR_ADJUSTMENTS_ALL, FND_USER, et HZ_CUST_ACCOUNTS.
Plage de dates: Le script inclut les paramètres :start_date et :end_date pour limiter la période d'extraction. Pour l'analyse initiale, une plage de 3 à 6 mois est recommandée pour maintenir le jeu de données gérable.
Filtre organisationnel: Le paramètre :org_id est indispensable pour les environnements multi-organisations afin de garantir que les données soient extraites pour la bonne unité commerciale. Vous pouvez trouver l'ID approprié dans la table HR_OPERATING_UNITS.
Bibliothèques Python: Cette méthode nécessite la bibliothèque pandas pour la manipulation de données et la bibliothèque oracledb pour se connecter à la base de données Oracle. Assurez-vous qu'elles sont installées dans votre environnement Python.
Considérations de performance: La requête utilise UNION ALL sur plusieurs grandes tables, ce qui peut être consommateur de ressources. Il est fortement conseillé d'exécuter cette extraction pendant les heures creuses ou sur une instance de rapport de la base de données pour éviter d'impacter les performances du système de production.

a Exemple de requête python

import pandas as pd
import oracledb
import sys

class=class="hl-string">"hl-comment"># --- Configuration: Replace with your database details ---
class=class="hl-string">"hl-comment"># For security, consider using environment variables or a secrets management tool.
db_user = class="hl-string">"your_user"
db_password = class="hl-string">"your_password"
class=class="hl-string">"hl-comment"># DSN (Data Source Name) e.g., class="hl-string">'your_db_host:1521/your_service_name'
db_dsn = class="hl-string">"your_dsn"

class=class="hl-string">"hl-comment"># --- Parameters for the extraction ---
class=class="hl-string">"hl-comment"># Use class="hl-string">'YYYY-MM-DD' format for dates
params = {
    class="hl-string">'start_date': class="hl-string">'2023-01-01',
    class="hl-string">'end_date': class="hl-string">'2023-12-31',
    class="hl-string">'org_id': 204 class=class="hl-string">"hl-comment"># Example Organization ID
}

sql_query = class="hl-string">"""
WITH base_invoices AS (
    -- Pre-filter invoices to the relevant period to improve performance
    SELECT
        rct.customer_trx_id,
        rct.trx_number,
        rct.org_id
    FROM
        RA_CUSTOMER_TRX_ALL rct
    WHERE
        rct.creation_date BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND rct.org_id = :org_id
        AND rct.cust_trx_type_id IN (SELECT cust_trx_type_id FROM ra_cust_trx_types_all WHERE type IN ('INV', 'CM', 'DM'))
)
-- 1. Invoice Generated
SELECT
    rct.trx_number AS InvoiceNumber,
    'Invoice Generated' AS ActivityName,
    rct.creation_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    RA_CUSTOMER_TRX_ALL rct
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.customer_trx_id = aps.customer_trx_id
    LEFT JOIN FND_USER fu ON rct.created_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)

UNION ALL

-- 2. Invoice Approved
-- This activity is highly dependent on custom workflows. 
-- This query assumes approval is marked by the invoice status becoming 'OP' (Open) from an 'IP' (Incomplete) state.
-- The event time is the last update date when this condition is met.
SELECT
    rct.trx_number AS InvoiceNumber,
    'Invoice Approved' AS ActivityName,
    rct.last_update_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    RA_CUSTOMER_TRX_ALL rct
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.customer_trx_id = aps.customer_trx_id
    LEFT JOIN FND_USER fu ON rct.last_updated_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND rct.complete_flag = 'Y'
  AND aps.status = 'OP'

UNION ALL

-- 3. Invoice Sent To Customer
-- This event is often not explicitly stored. We use the invoice date (TRX_DATE) of a completed invoice as a proxy.
SELECT
    rct.trx_number AS InvoiceNumber,
    'Invoice Sent To Customer' AS ActivityName,
    rct.trx_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    RA_CUSTOMER_TRX_ALL rct
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.customer_trx_id = aps.customer_trx_id
    LEFT JOIN FND_USER fu ON rct.last_updated_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND rct.complete_flag = 'Y'

UNION ALL

-- 4. Invoice Modified
-- Captures updates to an invoice before it is completed.
SELECT
    rct.trx_number AS InvoiceNumber,
    'Invoice Modified' AS ActivityName,
    rct.last_update_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    RA_CUSTOMER_TRX_ALL rct
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.customer_trx_id = aps.customer_trx_id
    LEFT JOIN FND_USER fu ON rct.last_updated_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND rct.last_update_date > rct.creation_date + INTERVAL '1' MINUTE
  AND rct.complete_flag = 'N'

UNION ALL

-- 5. Credit Memo Created
SELECT
    rct.trx_number AS InvoiceNumber,
    'Credit Memo Created' AS ActivityName,
    rct.creation_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    RA_CUSTOMER_TRX_ALL rct
    JOIN RA_CUST_TRX_TYPES_ALL rctt ON rct.cust_trx_type_id = rctt.cust_trx_type_id
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.customer_trx_id = aps.customer_trx_id
    LEFT JOIN FND_USER fu ON rct.created_by = fu.user_id
WHERE rct.previous_customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND rctt.type = 'CM'

UNION ALL

-- 6. Dispute Raised
SELECT
    rct.trx_number AS InvoiceNumber,
    'Dispute Raised' AS ActivityName,
    aps.dispute_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    RA_CUSTOMER_TRX_ALL rct
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.customer_trx_id = aps.customer_trx_id
    LEFT JOIN FND_USER fu ON aps.last_updated_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND aps.dispute_date IS NOT NULL

UNION ALL

-- 7. Payment Due Date Reached
SELECT
    rct.trx_number AS InvoiceNumber,
    'Payment Due Date Reached' AS ActivityName,
    aps.due_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    'SYSTEM' AS User,
    'System' AS Department,
    aps.status AS InvoiceStatus
FROM
    RA_CUSTOMER_TRX_ALL rct
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.customer_trx_id = aps.customer_trx_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)

UNION ALL

-- 8. Payment Reminder Issued
-- Assumes usage of Oracle Advanced Collections dunning letters
SELECT
    rct.trx_number AS InvoiceNumber,
    'Payment Reminder Issued' AS ActivityName,
    adl.dunning_letter_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    AR_DUNNING_LETTERS adl
    JOIN AR_DUNNING_LETTER_SETS adls ON adl.dunning_letter_set_id = adls.dunning_letter_set_id
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON adl.payment_schedule_id = aps.payment_schedule_id
    JOIN RA_CUSTOMER_TRX_ALL rct ON aps.customer_trx_id = rct.customer_trx_id
    LEFT JOIN FND_USER fu ON adl.last_updated_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)

UNION ALL

-- 9. Customer Payment Received
SELECT 
    rct.trx_number AS InvoiceNumber,
    'Customer Payment Received' AS ActivityName,
    acr.receipt_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM 
    AR_RECEIVABLE_APPLICATIONS_ALL ara
    JOIN AR_CASH_RECEIPTS_ALL acr ON ara.cash_receipt_id = acr.cash_receipt_id
    JOIN RA_CUSTOMER_TRX_ALL rct ON ara.applied_customer_trx_id = rct.customer_trx_id
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON ara.applied_payment_schedule_id = aps.payment_schedule_id
    LEFT JOIN FND_USER fu ON acr.created_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND ara.status = 'APP'

UNION ALL

-- 10. Payment Reversed
SELECT 
    rct.trx_number AS InvoiceNumber,
    'Payment Reversed' AS ActivityName,
    ara.reversal_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM 
    AR_RECEIVABLE_APPLICATIONS_ALL ara
    JOIN RA_CUSTOMER_TRX_ALL rct ON ara.applied_customer_trx_id = rct.customer_trx_id
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON ara.applied_payment_schedule_id = aps.payment_schedule_id
    LEFT JOIN FND_USER fu ON ara.last_updated_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND ara.reversal_date IS NOT NULL

UNION ALL

-- 11. Cash Applied/Reconciled
SELECT
    rct.trx_number AS InvoiceNumber,
    'Cash Applied/Reconciled' AS ActivityName,
    ara.apply_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    AR_RECEIVABLE_APPLICATIONS_ALL ara
    JOIN RA_CUSTOMER_TRX_ALL rct ON ara.applied_customer_trx_id = rct.customer_trx_id
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON ara.applied_payment_schedule_id = aps.payment_schedule_id
    LEFT JOIN FND_USER fu ON ara.created_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND ara.status = 'APP'

UNION ALL

-- 12. Write-Off Created
SELECT
    rct.trx_number AS InvoiceNumber,
    'Write-Off Created' AS ActivityName,
    adj.apply_date AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    AR_ADJUSTMENTS_ALL adj
    JOIN RA_CUSTOMER_TRX_ALL rct ON adj.customer_trx_id = rct.customer_trx_id
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.customer_trx_id = aps.customer_trx_id
    LEFT JOIN FND_USER fu ON adj.created_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND adj.type = 'INVOICE'
  AND adj.receivables_trx_id IN (SELECT receivables_trx_id FROM AR_RECEIVABLES_TRX_ALL WHERE name = 'Write-Off')

UNION ALL

-- 13. Invoice Closed
SELECT
    rct.trx_number AS InvoiceNumber,
    'Invoice Closed' AS ActivityName,
    aps.actual_date_closed AS EventTime,
    aps.amount_due_original AS TotalInvoiceAmount,
    aps.due_date AS DueDate,
    rct.bill_to_customer_id AS CustomerId,
    fu.user_name AS User,
    '[Department Placeholder]' AS Department,
    aps.status AS InvoiceStatus
FROM
    RA_CUSTOMER_TRX_ALL rct
    JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.customer_trx_id = aps.customer_trx_id
    LEFT JOIN FND_USER fu ON aps.last_updated_by = fu.user_id
WHERE rct.customer_trx_id IN (SELECT customer_trx_id FROM base_invoices)
  AND aps.status = 'CL'
"""

try:
    class=class="hl-string">"hl-comment"># Establish the connection to the Oracle database
    print(class="hl-string">"Connecting to Oracle database...")
    connection = oracledb.connect(user=db_user, password=db_password, dsn=db_dsn)

    print(class="hl-string">"Executing query...")
    class=class="hl-string">"hl-comment"># Execute the query and load data into a pandas DataFrame
    class=class="hl-string">"hl-comment"># Using a with statement ensures the connection is closed automatically
    with connection:
        df = pd.read_sql_query(sql_query, connection, params=params)

    print(fclass="hl-string">"Successfully extracted {len(df)} events.")

    class=class="hl-string">"hl-comment"># Data processing and cleanup
    if not df.empty:
        df[class="hl-string">'EVENTTIME'] = pd.to_datetime(df[class="hl-string">'EVENTTIME'])
        df.sort_values(by=[class="hl-string">'INVOICENUMBER', class="hl-string">'EVENTTIME'], inplace=True)

    class=class="hl-string">"hl-comment"># Save the DataFrame to a CSV file
    output_filename = class="hl-string">'oracle_ebs_billing_event_log.csv'
    df.to_csv(output_filename, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Event log saved to {output_filename}")

except oracledb.Error as e:
    print(fclass="hl-string">"Database error occurred: {e}")
    sys.exit(1)
except Exception as e:
    print(fclass="hl-string">"An error occurred: {e}")
    sys.exit(1)

Votre modèle de données `Order-to-Cash` - Facturation

Votre modèle de données `Order-to-Cash` - Facturation

Attributs De la commande au paiement - Facturation et encaissement

Activités De la commande au paiement - Facturation et encaissement

Guides d'extraction

Rapport Oracle BI Publisher pour les données de Facturation et de Recouvrement

Étapes

Configuration

a Exemple de requête sql

Requête SQL directe sur les schémas de base de données Oracle EBS

Étapes

Configuration

a Exemple de requête sql

Extraction par Script Python via le Connecteur de Base de Données Oracle

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Accélérez votre processus Order-to-Cash - Facturation et encaissement dès maintenant

Votre modèle de données Order-to-Cash - Facturation

Votre modèle de données Order-to-Cash - Facturation

Attributs De la commande au paiement - Facturation et encaissement

Activités De la commande au paiement - Facturation et encaissement

Guides d'extraction

Rapport Oracle BI Publisher pour les données de Facturation et de Recouvrement

Étapes

Configuration

a Exemple de requête sql

Requête SQL directe sur les schémas de base de données Oracle EBS

Étapes

Configuration

a Exemple de requête sql

Extraction par Script Python via le Connecteur de Base de Données Oracle

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Accélérez votre processus Order-to-Cash - Facturation et encaissement dès maintenant

Votre modèle de données `Order-to-Cash` - Facturation

Votre modèle de données `Order-to-Cash` - Facturation