> Amélioration continue des processus > De la Commande à l'Encaissement Facturation et Recouvrement > Oracle E Business Suite > Modèle de données

Votre Template de Données De la Commande à l'Encaissement - Facturation et Recouvrement

Oracle E-Business Suite

← Retour au Guide d'amélioration

De la Commande à l'Encaissement - Attributs de Facturation et de Recouvrement (21) De la Commande à l'Encaissement - Activités de Facturation et de Recouvrement (13) Guides d'extraction (3)

Votre Template de Données De la Commande à l'Encaissement - Facturation et Recouvrement

Ce template fournit une feuille de route claire pour la collecte des données essentielles requises pour analyser votre processus De la Commande à l'Encaissement - Facturation et Recouvrement. Il décrit les champs de données clés à inclure dans votre Event Log, 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

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

Télécharger le modèle

De la Commande à l'Encaissement - Attributs de Facturation et de Recouvrement

Ce sont les champs de données recommandés à inclure dans votre Event Log pour une analyse complète du processus De la Commande à l'Encaissement - Facturation et Recouvrement.

3 Obligatoire 6 Recommandé 12 Facultatif

	Nom	Description
	Heure de l'événement EventTime	La date et l'heure exactes de l'activité.
Description 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 basées sur le temps en process mining. Cet attribut est essentiel 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 cruciaux pour une analyse de processus fiable. Pourquoi c'est 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 goulots d'étranglement. Où obtenir 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.
Description Le Numéro de Facture est la pierre angulaire de l'analyse de facturation De la Commande à l'Encaissement, 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 vue complète de bout en bout 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 goulots d'étranglement qui retardent le paiement. C'est essentiel pour suivre les factures individuelles tout au long de leur parcours, de la création au règlement. Pourquoi c'est important C'est l'identifiant de cas essentiel qui relie tous les événements connexes, permettant la reconstruction et l'analyse de l'ensemble du processus de facturation pour chaque facture unique. Où obtenir 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.
Description 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 fondamental pour le Process Mining, car il est utilisé pour construire la carte des processus, analyser les variantes de processus et identifier les déviations ou les boucles de retravail. 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 c'est important Cet attribut constitue la base de la découverte et de la visualisation du flux de processus, permettant l'analyse des variantes de processus, des goulots d'étranglement et du retravail. Où obtenir 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éeÉchéance de Paiement AtteintePaiement client reçu
	Date d'échéance DueDate	La date à laquelle le client est censé régler la facture.
Description 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 essentiel 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 c'est 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. Où obtenir 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é.
Description 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 crucial 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 dashboard 'Temps de cycle d'approbation des factures' par département. Pourquoi c'est important Permet l'analyse des performances du processus par structure organisationnelle, mettant en évidence les différences entre les équipes et aidant à localiser les goulots d'étranglement spécifiques à un département. Où obtenir 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 Créances ClientsOpérations financièresServices de facturation
	ID client CustomerId	Un identifiant unique pour le client à qui la facture a été émise.
Description 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 retravail, et comparer les temps de traitement des factures entre les segments de clientèle. C'est essentiel pour passer d'une vue axée uniquement sur les processus à une analyse centrée sur le client. Pourquoi c'est important Permet une analyse centrée sur le client, aidant à identifier les schémas de paiement, les litiges fréquents ou les variations de processus spécifiques à certains clients. Où obtenir 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 tous les postes, taxes et frais.
Description Cet attribut représente la valeur financière totale de la facture envoyée au client. C'est une métrique fondamentale 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 c'est 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. Où obtenir 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.
Description 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 essentiel pour créer des tableaux de bord 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 résumé de haut niveau de la santé globale du portefeuille des comptes clients. Pourquoi c'est important Fournit une vue de l'état actuel des factures, essentielle pour les tableaux de bord opérationnels, la gestion des charges de travail et la priorisation des activités de recouvrement. Où obtenir 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é.
Description 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 essentiel 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 retravail ou aux délais d'approbation les plus longs, soutenant ainsi les efforts d'amélioration ciblée des processus. Pourquoi c'est 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. Où obtenir 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.
Description 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 éclairer les décisions stratégiques concernant les conditions de paiement à offrir aux différents segments de clientèle. Pourquoi c'est 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. Où obtenir Provient de la table RA_TERMS_B, liée via le TERM_ID dans la table RA_CUSTOMER_TRX_ALL. Exemples Net 30Net 60Payable à réception
	Délai moyen de recouvrement DaysSalesOutstanding	Le nombre de jours entre la génération de la facture et la réception du paiement.
Description 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 c'est 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é. Où obtenir Calculé lors de la transformation des données. Logique: Timestamp('Customer Payment Received') - Timestamp('Invoice Generated'). Exemples 304592
	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`.
Description Cet attribut fournit l'horodatage de la dernière extraction de données. Il est crucial pour comprendre la fraîcheur 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 c'est important Informe les utilisateurs sur la pertinence des données, s'assurant qu'ils comprennent à quel point l'analyse du processus est actuelle. Où obtenir 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.
Description 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 essentiel 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 c'est important Fournit un contexte essentiel pour tous les attributs financiers, garantissant une interprétation et une analyse précises dans un environnement multi-devises. Où obtenir Généralement trouvé dans la table RA_CUSTOMER_TRX_ALL, dans la colonne INVOICE_CURRENCY_CODE. Exemples USDEURGBP
	Durée du cycle d'approbation ApprovalCycleTime	La durée entre la génération et l'approbation d'une facture.
Description Cet attribut mesure le temps nécessaire au processus interne d'approbation des factures. C'est un indicateur clé de l'efficacité interne et une source fréquente de goulots d'étranglement dans le cycle de facturation global. Le calcul de cette durée pour chaque facture permet la création du dashboard 'Temps de cycle d'approbation des factures'. Il permet une analyse par département, utilisateur ou valeur de facture pour identifier les sources de retards d'approbation et mesurer l'impact des initiatives d'amélioration des processus. Pourquoi c'est important Identifie les goulots d'étranglement internes en mesurant l'efficacité du workflow d'approbation, cause fréquente de retards dans l'envoi des factures aux clients. Où obtenir Calculé lors de la transformation des données. Logique: Timestamp('Invoice Approved') - Timestamp('Invoice Generated'). Exemples 864001728003600
	Est `payé à temps` IsPaidOnTime	Un indicateur calculé qui indique si la facture a été payée à ou avant sa date d'échéance.
Description 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 c'est important Soutient directement le KPI 'Taux de paiement à temps' et simplifie les analyses en catégorisant les factures en groupes 'à temps' et 'en retard'. Où obtenir Calculé lors de la transformation des données. Logique: IF (Timestamp('Customer Payment Received') <= Date('DueDate')) THEN true ELSE false. Exemples truefaux
	Est un retravail IsRework	Un indicateur calculé indiquant si la facture a subi une activité de retravail, telle qu'une modification ou une nouvelle approbation.
Description Cet indicateur booléen est défini sur vrai si le flux de processus d'une facture contient des activités qui indiquent un retravail, 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 crucial pour des KPIs comme le 'Taux d'erreur de facturation' et le 'Taux de retravail manuel'. Il permet aux analystes de quantifier facilement la fréquence du retravail, 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 retravail. Pourquoi c'est 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 retravail. Où obtenir 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
	Nom du client CustomerName	Le nom légal du client à qui la facture a été émise.
Description 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 crucial pour créer des visualisations conviviales, comme un graphique à barres montrant le délai de paiement moyen par client. Pourquoi c'est important Améliore l'utilisabilité des tableaux de bord et des rapports en fournissant un nom lisible par l'homme pour le filtrage et le regroupement, rendant l'analyse plus accessible. Où obtenir 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.
Description 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 à l'Encaissement. 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 c'est important Connecte le processus de facturation au processus de vente en amont, permettant une analyse Order-to-Cash plus holistique et une investigation des causes profondes. Où obtenir Généralement trouvé 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
	Pays du client Country	Le pays de l'adresse de facturation du client.
Description 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 dashboard 'Insights sur le comportement de paiement des clients' pour voir si les retards de paiement moyens diffèrent significativement entre les pays. Pourquoi c'est 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. Où obtenir 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.
Description 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 essentiel pour la lignée 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 c'est important Assure la traçabilité et le contexte des données, ce qui est crucial pour la gouvernance des données et lors de l'intégration de données provenant de plusieurs systèmes d'entreprise. Où obtenir 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 au sein de l'entreprise qui a émis la facture.
Description 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 c'est 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. Où obtenir 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

De la Commande à l'Encaissement - Activités de Facturation et de Recouvrement

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

5 Recommandé 8 Facultatif

	Activité	Description
	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 c'est 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 à l'Encaissement. Où obtenir 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 c'est 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. Où obtenir 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 c'est 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 goulots d'étranglement précoces. Où obtenir Enregistré 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 c'est important C'est la dernière étape du processus de paiement et elle est critique 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. Où obtenir 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 c'est 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. Où obtenir 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 au sein des Comptes Clients.
Pourquoi c'est 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 essentielle à l'analyse des causes profondes des fuites de revenus et de l'insatisfaction client. Où obtenir Enregistré 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
	É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 c'est important Cet événement est essentiel 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. Où obtenir 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 c'est important Le suivi du temps d'approbation est essentiel 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. Où obtenir 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 complétée ou envoyée.
Pourquoi c'est 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 le retravail et son impact sur les temps de cycle, soutenant des KPI comme le 'Taux d'erreur de facturation'. Où obtenir 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 soulevé	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 c'est 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. Où obtenir 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 Enregistré 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 c'est 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. Où obtenir 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 c'est 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. Où obtenir 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
	Relance de Paiement Émise	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 c'est important Le suivi de cette activité est crucial 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. Où obtenir 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 Enregistré 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 crucial 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 crucial 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 timestamp 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 critique 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 Template de Données De la Commande à l'Encaissement - Facturation et Recouvrement

Votre Template de Données De la Commande à l'Encaissement - Facturation et Recouvrement

De la Commande à l'Encaissement - Attributs de Facturation et de Recouvrement

De la Commande à l'Encaissement - Activités de Facturation et de Recouvrement

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 Template de Données De la Commande à l'Encaissement - Facturation et Recouvrement

Votre Template de Données De la Commande à l'Encaissement - Facturation et Recouvrement

De la Commande à l'Encaissement - Attributs de Facturation et de Recouvrement

De la Commande à l'Encaissement - Activités de Facturation et de Recouvrement

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