> Amélioration continue des processus > Record to Report Écriture comptable > `Oracle Fusion Financials` > Modèle de données

Votre modèle de données Record to Report - Écriture comptable

Oracle Fusion Financials

← Retour au Guide d'amélioration

Record to Report - Attributs des écritures comptables (22) Record to Report - Activités des écritures comptables (12) Guides d'extraction (4)

Votre modèle de données Record to Report - Écriture comptable

Ce modèle de données fournit un guide complet pour l'extraction et la structuration de vos données d'écritures comptables Oracle Fusion Financials. Il décrit les attributs essentiels à collecter et les activités clés à suivre, garantissant la capture de toutes les informations nécessaires pour une analyse de processus robuste. Vous trouverez également des conseils pratiques sur la façon d'extraire ces données directement de votre système.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction pour Oracle Fusion Financials

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

Télécharger le modèle

Record to Report - Attributs des écritures comptables

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de votre processus Record to Report - Écritures comptables.

5 Obligatoire 6 Recommandé 11 Facultatif

	Nom	Description
	Activité ActivityName	Le nom de l'événement commercial ou de la tâche spécifique qui s'est produit à un moment donné dans le processus d'écriture comptable.
Description Le Nom de l'activité décrit une seule étape du cycle de vie de l'écriture comptable, telle que 'Création d'écriture comptable' ou 'Écriture comptable approuvée'. Ces données sont cruciales pour construire la carte de processus et comprendre la séquence des événements. L'analyse des activités permet l'identification du flux de processus, y compris les chemins standard, les écarts et les boucles de retravail. En suivant les différentes activités, nous pouvons mesurer le temps passé à des étapes spécifiques, telles que l'approbation, et identifier les étapes les plus chronophages ou sujettes aux erreurs. Pourquoi c'est important Il définit les étapes du processus, constituant l'épine dorsale de la carte de processus et permettant l'analyse du flux, des goulots d'étranglement et des variations. Où obtenir Cet attribut est généralement dérivé des changements de statut, des journaux d'événements ou des tables de piste d'audit associées aux objets d'écriture comptable dans le module Grand Livre. Exemples Écriture de journal crééeÉcriture soumise pour approbationÉcriture comptable approuvéeÉcriture comptable validée
	Heure de début EventTime	L'horodatage indiquant quand une activité ou un événement spécifique s'est produit.
Description Cet horodatage marque la date et l'heure exactes d'exécution d'une activité. C'est l'élément temporel principal utilisé en Process Mining pour déterminer la séquence des événements et calculer les durées entre eux. L'exactitude de l'Heure de l'événement est critique pour toutes les analyses basées sur le temps, y compris le calcul des temps de cycle, l'identification des goulots d'étranglement et le suivi des performances par rapport aux accords de niveau de service. Il fournit l'ordre chronologique nécessaire pour reconstituer le flux de processus tel qu'il s'est produit. Pourquoi c'est important Cet horodatage est essentiel pour ordonner les événements, calculer toutes les durées de processus et effectuer toute analyse basée sur le temps. Où obtenir Cette information est généralement stockée dans des tables de piste d'audit ou comme une 'Date de dernière mise à jour' ou 'Date de création' sur des tables de transaction comme GL_JE_HEADERS et GL_JE_LINES pour des événements spécifiques. Exemples 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	ID d'écriture comptable JournalEntryId	L'identifiant unique pour une seule écriture comptable, liant toutes les activités de transaction financière associées.
Description L'ID d'écriture comptable sert d'identifiant de cas principal, liant de manière unique toutes les activités liées à un ensemble spécifique de transactions financières. Cela permet de suivre le cycle de vie complet d'une seule écriture comptable, de l'initiation à la comptabilisation finale, garantissant que tous les débits et crédits sont pris en compte. En Process Mining, cet ID est essentiel pour reconstituer le parcours de bout en bout de chaque écriture comptable. Il connecte des événements disparates comme 'Création d'écriture comptable', 'Écriture soumise pour approbation' et 'Écriture comptable comptabilisée' en un flux de processus cohérent, permettant l'analyse des temps de cycle, des goulots d'étranglement et des variations de processus. Pourquoi c'est important Ceci est la clé fondamentale pour suivre une écriture comptable de bout en bout, permettant d'analyser l'ensemble du flux de processus pour chaque cas unique. Où obtenir Ceci est une clé primaire trouvée dans les tables principales du Grand Livre telles que GL_JE_HEADERS et GL_JE_LINES. Exemples JE100523JE202311001882019
	Dernière mise à jour des données LastDataUpdate	Le timestamp de la dernière actualisation des données ou de l'extraction du système source.
Description Cet attribut enregistre la dernière mise à jour de l'ensemble de données. Il fournit un contexte sur la fraîcheur des données analysées, ce qui est important pour comprendre la pertinence des informations dérivées. Dans toute analyse, en particulier dans les tableaux de bord opérationnels, connaître l'heure de la dernière mise à jour des données est essentiel pour que les utilisateurs puissent faire confiance aux données et prendre des décisions éclairées. Il communique clairement le point de coupure pour les données incluses dans le modèle de Process Mining. Pourquoi c'est important Indique la fraîcheur des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse des processus et peuvent faire confiance aux insights. Où obtenir Cette valeur est générée et stockée pendant le processus d'extraction et de transformation des données. C'est typiquement l'horodatage de l'achèvement du job ETL/ELT. Exemples 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Système source SourceSystem	Le système ou module d'où proviennent les données.
Description Cet attribut identifie le système source d'où les données de processus ont été extraites. Dans un paysage informatique complexe, les données peuvent provenir de plusieurs systèmes intégrés, et ce champ aide à les différencier. En analyse de processus, connaître le système source est crucial pour comprendre les variations de processus qui peuvent être dues à des comportements système différents. Cela aide également à la validation des données et au dépannage en retraçant les données jusqu'à leur origine. Pourquoi c'est important Identifie l'origine des données, ce qui est crucial pour la gouvernance des données, la validation et la compréhension des variations de processus entre différents systèmes. Où obtenir Ceci est souvent une valeur statique configurée lors de l'extraction des données, ou il pourrait s'agir d'un champ dans les tables source identifiant le système d'entrée. Exemples Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Catégorie d'écriture JournalCategory	La catégorie de l'écriture comptable, telle que 'Charge à payer', 'Ajustement' ou 'Reclassification'.
Description La catégorie d'écriture classe les écritures en fonction de leur objectif métier. Cette classification permet une analyse plus granulaire du processus, car différentes catégories peuvent avoir des flux de processus, des règles d'approbation ou des temps de cycle distincts. Par exemple, les écritures de régularisation de fin de mois pourraient avoir un processus plus complexe et urgent que les régularisations de routine. L'analyse du processus par catégorie aide à découvrir ces variations et à adapter les améliorations à des types spécifiques d'écritures comptables. Pourquoi c'est important Permet de segmenter le processus par l'objet métier de l'écriture, révélant des comportements et des performances différents pour les divers types d'écritures. Où obtenir Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé JE_CATEGORY. Exemples RégularisationManuelAjustementRéévaluation
	Département Utilisateur UserDepartment	Le département ou l'équipe auquel appartient l'utilisateur qui a effectué l'activité.
Description Cet attribut fournit un contexte organisationnel en liant une activité à un département spécifique, tel que 'Finance', 'Opérations Comptables' ou 'Audit Interne'. Il est généralement dérivé des données de base des utilisateurs. L'analyse par Département utilisateur aide à identifier les goulots d'étranglement interdépartementaux, à comparer la performance des équipes et à comprendre comment l'exécution des processus diffère au sein de l'organisation. Elle est précieuse pour l'allocation des ressources et les initiatives d'amélioration des processus ciblées. Pourquoi c'est important Fournit un contexte organisationnel, permettant une analyse des performances par équipe ou département et mettant en évidence les inefficacités interfonctionnelles. Où obtenir Ceci n'est généralement pas dans les tables de transaction. Il doit être extrait en joignant le UserName à une table de données de base utilisateur ou aux données du système RH. Exemples Comptabilité généraleReporting financierComptabilité Fournisseurs
	Montant de l'écriture JournalAmount	La valeur monétaire totale de l'écriture comptable, généralement la somme des débits.
Description Cet attribut représente la valeur financière totale transigée dans l'écriture comptable. Le montant peut être un facteur significatif influençant le processus. Par exemple, les écritures de grande valeur peuvent nécessiter des étapes d'approbation supplémentaires ou des examens plus approfondis. L'analyse du Montant de l'écriture permet la segmentation des cas par impact financier. Elle aide à répondre à des questions comme 'Les écritures de grande valeur prennent-elles plus de temps à approuver ?' ou 'Les rejets sont-ils plus fréquents pour les écritures dépassant un certain seuil ?'. Cela fournit un contexte métier crucial au flux de processus. Pourquoi c'est important Fournit un contexte métier essentiel, permettant une analyse basée sur l'impact financier et aidant à identifier si les écritures de grande valeur suivent un processus différent. Où obtenir Cette valeur est généralement calculée comme la somme des débits ou des crédits de la table GL_JE_LINES pour une écriture comptable donnée. Exemples 5000.00125000.75750.50
	Motif de refus RejectionReason	Une description textuelle ou un code expliquant pourquoi une écriture comptable a été rejetée.
Description Lorsqu'une écriture comptable est rejetée pendant le processus d'approbation, cet attribut capture la raison du rejet. Il peut s'agir d'un code prédéfini ou d'un commentaire en texte libre de l'approbateur. C'est l'un des attributs les plus importants pour l'analyse des causes profondes des inefficacités de processus. En analysant les raisons de rejet les plus courantes, les organisations peuvent identifier des domaines d'amélioration, tels qu'une meilleure formation pour les préparateurs, des directives plus claires ou des améliorations des contrôles système. Il prend directement en charge le tableau de bord 'Analyse du taux de rejet des écritures comptables'. Pourquoi c'est important Offre un aperçu direct des causes profondes du retravail et des retards de processus, permettant des améliorations ciblées pour réduire les taux de rejet. Où obtenir Cette information peut être stockée dans des tables de workflow ou de piste d'audit associées au processus d'approbation, ou dans un champ de notes sur l'en-tête de l'écriture. Exemples Combinaison de comptes incorrecteDocumentation justificative insuffisanteDépasse le budget
	Source de l'écriture JournalSource	Le grand livre auxiliaire ou la source qui a généré l'écriture comptable, tels que 'Comptes fournisseurs', 'Comptes clients' ou 'Manuel'.
Description Cet attribut indique l'origine de l'écriture comptable au sein du système ERP. Les écritures peuvent être créées manuellement dans le Grand Livre ou générées automatiquement à partir de grands livres auxiliaires comme les Comptes fournisseurs, les Comptes clients ou les Immobilisations. La Source d'écriture est un attribut clé pour l'analyse de l'automatisation. Il aide à différencier les écritures manuelles des écritures générées par le système, soutenant le KPI 'Taux d'écritures comptables automatisées'. Les processus pour les écritures provenant de différentes sources varient souvent de manière significative en termes de complexité et d'efficacité. Pourquoi c'est important Distingue les saisies manuelles des saisies automatisées, ce qui est essentiel pour mesurer les taux d'automatisation et analyser les différences de processus. Où obtenir Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé JE_SOURCE. Exemples ManuelComptes fournisseursActifsComptes clients
	Utilisateur UserName	L'utilisateur qui a effectué l'activité, telle que la création, l'approbation ou la comptabilisation de l'écriture comptable.
Description Cet attribut identifie l'employé ou l'utilisateur système spécifique responsable de l'exécution d'une activité. Il est crucial pour comprendre la répartition de la charge de travail, la performance et l'identification des goulots d'étranglement individuels. En analyse, UserName permet de filtrer les processus par utilisateur, de comparer l'efficacité des utilisateurs et d'enquêter sur les raisons des retards ou des erreurs. Il prend directement en charge les tableaux de bord comme 'Charge de travail et efficacité des utilisateurs par équipe' et les KPI comme 'Indice de goulot d'étranglement des écritures par utilisateur'. Pourquoi c'est important Attribue la responsabilité des étapes du processus, permettant l'analyse de la charge de travail des utilisateurs, de la performance individuelle et des besoins en formation. Où obtenir Trouvé dans les tables de transactions comme GL_JE_HEADERS (par exemple, CREATED_BY, LAST_UPDATED_BY) et les tables d'audit associées. Exemples john.doesusan.smithautoprocess_user
	Date cible de comptabilisation TargetPostingDate	La date prédéterminée à laquelle l'écriture comptable est censée être comptabilisée.
Description La Date Cible de Comptabilisation représente la date limite pour comptabiliser une écriture comptable dans le grand livre général, souvent déterminée par les accords de niveau de service (SLA) ou les calendriers de clôture de fin de mois. Elle sert de référence pour mesurer la performance. Cet attribut est essentiel pour calculer le KPI 'Taux de comptabilisation des écritures dans les délais'. En comparant la date de comptabilisation réelle à cette cible, le système peut automatiquement marquer les écritures comme à temps ou en retard, offrant une mesure claire de l'adhérence du processus aux calendriers. Pourquoi c'est important Définit l'accord de niveau de service ou le délai pour la validation, permettant le calcul des KPI de performance dans les délais. Où obtenir Ceci n'est peut-être pas un champ standard. Il pourrait être dérivé de règles métier basées sur la date de création, la période comptable ou la catégorie d'écriture. Exemples 2023-10-312023-11-302024-01-05
	Devise CurrencyCode	Le code de devise pour le montant de l'écriture comptable, tel que USD, EUR ou GBP.
Description Le Code de devise spécifie la devise des montants financiers de l'écriture comptable. Ceci est essentiel pour les organisations multinationales qui effectuent des transactions en plusieurs devises. Cet attribut garantit que les valeurs financières sont interprétées correctement. Il permet de filtrer par devise et est un champ nécessaire lors de toute analyse impliquant la comparaison ou l'agrégation de montants monétaires entre différentes régions. Pourquoi c'est important Fournit le contexte nécessaire pour toutes les sommes financières, assurant une interprétation précise et permettant une analyse spécifique aux différentes devises. Où obtenir Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé CURRENCY_CODE. Exemples USDEURGBPJPY
	Est un retravail IsRework	Un indicateur calculé qui est vrai si l'écriture comptable a subi un cycle de rejet et de correction.
Description Cet attribut booléen est calculé pour identifier les cases ayant fait l'objet d'un retravail. Il est généralement défini sur « true » pour toute activité suivant un event « Journal Entry Rejected », tel que « Journal Corrected and Resubmitted ». « Is Rework » est un attribut d'analyse puissant : il permet de quantifier facilement le volume et l'impact des boucles de retravail. Il alimente directement le KPI « Average Journal Rework Rate » et facilite la comparaison du flux et de la durée des cases avec retravail par rapport à ceux traités correctement dès la première fois. Pourquoi c'est important Signale directement les cas ayant traversé des boucles de retravail inefficaces, facilitant la quantification de la fréquence et de l'impact des échecs de processus. Où obtenir Ceci n'est pas disponible dans le système source. Il est calculé au sein de l'outil de Process Mining en analysant la séquence des activités pour chaque cas. Exemples truefaux
	Heure de fin EndTime	L'horodatage indiquant la date et l'heure de réalisation d'une activité spécifique.
Description L'Heure de fin marque l'achèvement d'une activité. Alors que l'Heure de début enregistre le début, l'Heure de fin fournit le point de clôture, permettant le calcul précis du temps de traitement pour cette étape spécifique. Ceci est essentiel pour calculer les temps de traitement des activités, qui est une métrique clé pour identifier les goulots d'étranglement et mesurer l'efficacité des ressources. Par exemple, la différence entre l'Heure de fin et l'Heure de début de l'activité 'Écriture comptable révisée' donne le temps réel qu'un réviseur a consacré à la tâche. Pourquoi c'est important Il permet le calcul de la durée réelle ou du temps de traitement des activités individuelles, ce qui est essentiel pour identifier les problèmes d'efficacité. Où obtenir Similaire à l'heure de début, cela se trouve souvent dans les tables de piste d'audit ou peut être déduit de l'heure de début de l'activité suivante dans le processus. Exemples 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Indicateur d'annulation ReversalIndicator	Un indicateur qui signale si l'écriture comptable est une contre-passation d'une autre écriture.
Description Cet attribut booléen identifie les écritures comptables créées pour annuler une écriture précédemment comptabilisée. Les annulations sont un type spécifique d'écriture comptable qui suit souvent un processus distinct, et parfois problématique. L'analyse de cet indicateur est essentielle pour soutenir le tableau de bord 'Performance du processus d'annulation des écritures'. Elle permet d'isoler les processus d'annulation pour mesurer leur fréquence, leurs causes et leurs temps de cycle, aidant à identifier les problèmes sous-jacents dans les écritures originales qui nécessitent une annulation. Pourquoi c'est important Aide à isoler et à analyser le processus de contre-passation, qui est souvent un indicateur d'erreurs ou de problèmes dans la transaction originale. Où obtenir Il peut s'agir d'un indicateur spécifique dans la table GL_JE_HEADERS, tel que ACCRUAL_REV_FLAG, ou identifié via des liens vers l'écriture originale en cours d'annulation. Exemples truefaux
	Nom du grand livre LedgerName	Le nom du grand livre général où l'écriture comptable est enregistrée.
Description Le Nom du grand livre identifie le grand livre spécifique auquel appartient l'écriture comptable. Dans les organisations avec plusieurs entités légales ou exigences de reporting, il peut y avoir plusieurs grands livres, tels qu'un grand livre principal pour la comptabilité d'entreprise et des grands livres secondaires pour le reporting statutaire local. Cet attribut est essentiel pour filtrer et comparer les processus entre différentes entités légales ou unités commerciales. Il garantit que les analyses sont menées dans le bon contexte organisationnel, ce qui est particulièrement important pour la conformité financière et le reporting. Pourquoi c'est important Permet de filtrer et de comparer l'analyse des processus entre différentes entités juridiques ou cadres comptables, ce qui est vital pour les grandes organisations. Où obtenir Trouvé dans la table GL_JE_HEADERS, généralement lié via un LEDGER_ID qui peut être joint à GL_LEDGERS pour obtenir le nom. Exemples Grand Livre Principal des États-UnisGrand Livre Législatif du Royaume-UniGrand livre de consolidation global
	Période comptable AccountingPeriod	La période fiscale à laquelle l'écriture comptable est comptabilisée, telle que 'Janv-24'.
Description La Période comptable spécifie la période financière au cours de laquelle la transaction est reconnue. Ceci est fondamental pour tous les rapports et analyses financiers. En Process Mining, cet attribut est crucial pour l'analyse des tendances. Il permet de comparer la performance des processus, tels que les temps de cycle ou les taux de rejet, sur différents mois ou trimestres. Cela aide à identifier les effets de saisonnalité, comme une charge de travail accrue lors de la clôture de fin de mois, et à mesurer l'impact des améliorations de processus au fil du temps. Pourquoi c'est important Permet l'analyse des tendances des KPI au fil du temps, aidant à mesurer l'amélioration des processus et à identifier les schémas saisonniers comme les pressions de fin de mois. Où obtenir Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé PERIOD_NAME. Exemples Janv-24Fév-24Mars-24
	Statut de validation PostingStatus	Le statut de comptabilisation actuel de l'écriture comptable, par exemple, 'Non comptabilisée' ou 'Comptabilisée'.
Description Cet attribut reflète l'état actuel de l'écriture comptable par rapport à sa comptabilisation dans le grand livre général. C'est un indicateur clé de l'emplacement d'une écriture comptable dans son cycle de vie, en particulier pour les cas en cours. Le Statut de comptabilisation est crucial pour le dashboard 'Suivi du statut des écritures comptables en temps réel', offrant un aperçu de toutes les écritures actives. Il aide à surveiller les arriérés d'écritures non comptabilisées et à identifier les retards dans les étapes finales du processus. Pourquoi c'est important Indique l'état actuel d'une écriture comptable, ce qui est essentiel pour surveiller les arriérés et suivre le statut des écritures en cours. Où obtenir Disponible dans la table GL_JE_HEADERS, généralement dans une colonne comme STATUS ou POSTING_STATUS. Exemples ComptabiliséNon comptabiliséeErreur
	Temps d'approbation de l'écriture JournalApprovalTime	La durée calculée entre la soumission de l'écriture et la décision finale d'approbation ou de rejet.
Description Cette métrique mesure le temps écoulé entre la soumission d'une écriture pour approbation et son approbation ou son rejet. C'est une mesure critique de l'efficacité du workflow d'approbation. Le Temps d'approbation d'écriture est une entrée directe pour le KPI 'Temps moyen d'approbation d'écriture' et le tableau de bord 'Goulots d'étranglement d'approbation d'écriture comptable'. L'analyse de cette durée aide à identifier les retards dans la chaîne d'approbation, qu'ils soient causés par des approbateurs spécifiques, des départements ou des types d'écritures. Pourquoi c'est important Mesure directement l'efficacité du workflow d'approbation, qui est souvent une source majeure de retards de processus. Où obtenir Ceci est une métrique calculée au sein de l'outil de Process Mining. C'est la différence de temps entre les événements 'Écriture soumise pour approbation' et 'Écriture comptable approuvée' ou 'Écriture comptable rejetée'. Exemples P2DT4H30MPT8HP5D
	Temps de cycle de bout en bout EndToEndCycleTime	La durée totale calculée entre la création d'une écriture comptable et son rapprochement final.
Description Cette métrique représente le temps total qu'une écriture comptable passe dans l'ensemble du processus, du tout premier événement 'Création d'écriture comptable' à l'événement final 'Écriture comptable rapprochée'. Elle offre une vue holistique de la performance du processus. Ceci est un KPI primaire pour mesurer l'efficacité globale du processus. Il est utilisé dans les tableaux de bord de tendance pour suivre l'impact des initiatives d'amélioration au fil du temps et fournit une base de référence par rapport à laquelle toutes les modifications de processus peuvent être mesurées. Pourquoi c'est important Offre une mesure globale de la santé et de l'efficacité de l'ensemble du processus, en faisant un indicateur clé pour le reporting exécutif. Où obtenir Cette métrique est calculée par la plateforme de Process Mining comme la différence de temps entre les horodatages du premier et du dernier événement pour chaque cas. Exemples P10DT5HP4DT12HP22D
	Validation dans les délais IsOnTimePosting	Un indicateur calculé qui est vrai si l'écriture comptable a été validée à la date cible ou avant.
Description Cet attribut booléen est obtenu en comparant le timestamp de l'activité « Journal Entry Posted » avec la « Target Posting Date ». Si la publication intervient au plus tard à la date cible, la valeur est « true » ; sinon, elle est « false ». Cet attribut soutient directement le KPI « On-Time Journal Posting Rate » en simplifiant son calcul. Il permet de filtrer et d'analyser facilement les saisies tardives afin d'identifier les causes de retard récurrentes, comme certaines catégories de journaux ou des approbateurs spécifiques. Pourquoi c'est important Fournit un résultat clair et binaire pour la performance de la comptabilisation, simplifiant l'analyse des taux de comptabilisation dans les délais et les causes profondes des retards. Où obtenir Cet attribut est calculé par l'outil de Process Mining. Il nécessite l'attribut 'TargetPostingDate' et l'horodatage de l'activité 'Écriture comptable comptabilisée'. Exemples truefaux

Obligatoire Recommandé Facultatif

Record to Report - Activités des écritures comptables

Ce sont les étapes et les jalons clés du processus à capturer dans votre journal d'événements pour une découverte de processus précise dans les écritures comptables.

5 Recommandé 7 Facultatif

	Activité	Description
	Écriture comptable approuvée	L'approbateur désigné a formellement approuvé l'écriture comptable, confirmant son exactitude et sa validité. C'est la dernière étape du workflow d'approbation, ouvrant la voie à la comptabilisation.
Pourquoi c'est important Ce jalon marque la fin du processus d'approbation. Le temps entre la soumission et l'approbation est un KPI clé pour mesurer l'efficacité du workflow et identifier les goulots d'étranglement d'approbation. Où obtenir Cet événement est déduit d'un changement de statut dans la table GL_JE_HEADERS, où le APPROVAL_STATUS_CODE est mis à jour en 'APPROVED'. Les tables de workflow contiennent l'identité et l'horodatage de l'approbateur. Capture Suivre l'horodatage lorsque APPROVAL_STATUS_CODE dans GL_JE_HEADERS passe à 'APPROVED'. Type d'événement inferred
	Écriture comptable rapprochée	L'écriture comptable a été rapprochée et apurée lors d'un processus de rapprochement des comptes de fin de période. Ceci confirme que la transaction s'aligne avec d'autres données financières, telles que les relevés bancaires.
Pourquoi c'est important Cette activité constitue un véritable point final pour le cycle de vie de l'écriture. Mesurer le temps entre la comptabilisation et le rapprochement est un KPI clé pour évaluer l'efficacité du processus de clôture financière. Où obtenir Cet événement est généralement capturé dans Oracle Financial Consolidation and Close Cloud Service (FCCS) ou Account Reconciliation Cloud Service (ARCS), et non dans le Grand Livre lui-même. Il est déduit d'un changement de statut sur l'enregistrement de rapprochement lié à l'écriture. Capture Corréler les données des écritures avec les mises à jour du statut de rapprochement à partir des tables ARCS ou FCCS. Type d'événement inferred
	Écriture comptable validée	Les données financières de l'écriture comptable ont été enregistrées avec succès dans le Grand Livre. Les débits et crédits sont désormais reflétés dans les soldes des comptes.
Pourquoi c'est important Ceci est un jalon critique représentant l'entrée de l'écriture dans le registre financier officiel. Il est essentiel pour mesurer le taux de comptabilisation dans les délais et le temps total de la création à la comptabilisation. Où obtenir Ceci est déduit d'un changement de statut dans la table GL_JE_HEADERS, où le champ STATUS passe à 'P' (Comptabilisée). La table GL_JE_BATCHES a également un statut de comptabilisation. Capture Suivre l'horodatage lorsque STATUS dans GL_JE_HEADERS passe à 'P'. Type d'événement inferred
	Écriture de journal créée	Cette activité marque le début du processus d'écriture comptable. Elle représente le moment où un utilisateur crée un nouvel en-tête d'écriture et commence à saisir des données, mais avant qu'elle ne soit soumise pour examen ou approbation.
Pourquoi c'est important Ceci est l'événement de démarrage principal du processus. L'analyse du temps écoulé entre cette activité et les étapes ultérieures aide à mesurer l'efficacité de la saisie initiale des données et le temps de cycle global du processus. Où obtenir Cet événement est généralement déduit de l'horodatage de la date de création dans la table GL_JE_HEADERS pour un ID d'écriture comptable spécifique. L'utilisateur qui a créé l'enregistrement est également disponible dans cette table. Capture Utiliser la CREATION_DATE de la table GL_JE_HEADERS. Type d'événement inferred
	Écriture soumise pour approbation	Cette activité se produit lorsque l'utilisateur soumet formellement l'écriture comptable complétée dans le workflow d'approbation. Elle fait passer l'écriture d'un état de brouillon ou incomplet à un état en attente d'approbation.
Pourquoi c'est important Ceci est un jalon critique qui lance le décompte pour mesurer les temps de cycle d'approbation et identifier les goulots d'étranglement. Il sépare la phase de saisie des données de la phase d'examen et d'approbation. Où obtenir Cet événement est déduit d'un changement de statut dans la table GL_JE_HEADERS, spécifiquement lorsque le APPROVAL_STATUS_CODE change pour une valeur telle que 'REQUIRED' ou 'INITIATED'. L'horodatage de la date de soumission peut également être enregistré. Capture Suivre l'horodatage lorsque APPROVAL_STATUS_CODE dans GL_JE_HEADERS change pour indiquer la soumission. Type d'événement inferred
	Contre-passation d'écriture traitée	Une écriture comptable de contre-passation a été créée et validée pour annuler l'impact financier de l'écriture originale au cours d'une période ultérieure. Il s'agit d'une action courante pour les écritures de régularisation.
Pourquoi c'est important Le suivi des annulations aide à identifier les types d'écritures qui sont fréquemment annulées et à analyser l'efficacité du processus d'annulation lui-même. Cela peut indiquer des problèmes de gestion des charges à payer. Où obtenir Ceci est déduit en identifiant une nouvelle écriture comptable qui est explicitement liée à l'originale comme son annulation. La table GL_JE_HEADERS contient des champs comme REVERSAL_PERIOD et REVERSAL_FLAG pour identifier et lier ces écritures. Capture Identifier la date de création et de validation de la nouvelle écriture dont l'en-tête fait référence à l'écriture originale comme étant contre-passée. Type d'événement inferred
	Documentation justificative jointe	Représente l'action de joindre des documents justificatifs, tels que des factures ou des feuilles de calcul, à l'écriture comptable. Ceci est souvent fait pour fournir un contexte et des preuves aux auditeurs et aux approbateurs.
Pourquoi c'est important Le suivi de cette activité aide à comprendre si les retards sont causés par des documents manquants. Il fournit également des informations sur la conformité et l'exhaustivité des écritures comptables avant qu'elles n'entrent dans le workflow d'approbation. Où obtenir Cela peut être difficile à suivre comme un événement discret. Cela peut être déduit des horodatages dans les tables de pièces jointes comme FND_ATTACHED_DOCUMENTS, liées à l'enregistrement de l'écriture comptable dans GL_JE_HEADERS. Capture Déduire de la date de création des enregistrements dans FND_ATTACHED_DOCUMENTS liés à l'écriture. Type d'événement inferred
	Écriture comptable rejetée	Un approbateur a examiné l'écriture comptable et l'a rejetée en raison d'erreurs, d'un manque de documentation ou de violations de politique. Cette action renvoie l'écriture au créateur pour correction.
Pourquoi c'est important Cette activité est cruciale pour l'analyse des boucles de retravail, des taux de rejet et des métriques de 'bonne première fois'. Une fréquence élevée de rejets indique des problèmes de qualité des données ou de formation. Où obtenir Ceci est déduit d'un changement de statut dans la table GL_JE_HEADERS lorsque le APPROVAL_STATUS_CODE est mis à jour en 'REJETÉE'. L'historique du workflow enregistrera l'utilisateur et l'horodatage de cette action. Capture Suivre l'horodatage lorsque APPROVAL_STATUS_CODE dans GL_JE_HEADERS est défini sur 'REJETÉE'. Type d'événement inferred
	Écriture comptable révisée	Une étape de révision qui peut avoir lieu avant ou dans le cadre du processus d'approbation formel. Elle représente une vérification par un pair ou un gestionnaire pour garantir l'exactitude et la conformité avant le passage à l'approbateur final.
Pourquoi c'est important Isoler cette activité aide à différencier les temps de révision préliminaires des temps d'approbation finaux. Cela peut révéler des goulots d'étranglement cachés si l'étape de révision est informelle mais chronophage. Où obtenir Ceci peut être une étape explicite dans un workflow d'approbation à plusieurs étapes, capturée dans les tables d'historique de workflow. Si informel, il n'est pas capturé. Il peut être déduit si une action utilisateur spécifique est enregistrée avant la décision d'approbation finale. Capture Analyser les tables d'historique de workflow pour les étapes d'approbation ou de révision intermédiaires avant le statut final 'Approuvé'. Type d'événement inferred
	Écriture corrigée et resoumise	Après le rejet d'une écriture comptable, le créateur apporte les corrections nécessaires et la soumet à nouveau pour approbation. Cette activité représente le début d'un nouveau cycle d'approbation pour la même écriture.
Pourquoi c'est important Le suivi du retravail est essentiel pour comprendre l'inefficacité des processus. Cette activité, combinée à 'Écriture comptable rejetée', permet la mesure du temps et de la fréquence de retravail. Où obtenir Ceci est un événement 'Écriture soumise pour approbation' ultérieur pour une écriture qui était précédemment dans un état 'REJETÉE'. Il est identifié en analysant la séquence des changements de statut pour un seul ID d'écriture comptable. Capture Identifier un horodatage d'événement de soumission qui se produit après un événement de rejet pour le même ID de cas. Type d'événement inferred
	Validation de l'écriture initiée	Le processus de comptabilisation de l'écriture approuvée dans le Grand Livre a été lancé. Cela peut être une étape automatisée ou manuelle qui met l'écriture en file d'attente pour traitement par le programme de comptabilisation.
Pourquoi c'est important Cette activité sépare l'approbation du processus technique de comptabilisation. Les retards entre l'approbation et l'initiation de la comptabilisation peuvent indiquer des problèmes de planification ou des contraintes de ressources dans le moteur de comptabilisation. Où obtenir Cela peut être déduit des changements de statut dans la table GL_JE_BATCHES, ou par l'heure de soumission de la requête concurrente de comptabilisation associée au lot d'écritures. Capture Identifier l'heure de soumission de la demande pour le programme de validation du grand livre général pour le lot d'écritures spécifique. Type d'événement inferred
	Validation vérifiée	Une étape de vérification post-validation où un utilisateur ou un système confirme que l'écriture a été correctement validée et que les soldes sont conformes aux attentes. Il s'agit souvent d'une étape de contrôle manuel.
Pourquoi c'est important L'analyse de cette activité aide à comprendre le temps consacré aux contrôles manuels et à l'assurance qualité après la validation. Elle peut mettre en évidence des opportunités d'automatisation des processus de vérification. Où obtenir Il est peu probable que ce soit un événement explicite dans Oracle Fusion. Il faudrait le déduire d'autres actions, telles qu'un utilisateur exécutant un rapport spécifique ou un champ de statut personnalisé étant mis à jour, ce qui n'est pas standard. Capture Nécessite une logique personnalisée, telle que le suivi du temps d'exécution des rapports de vérification ou les mises à jour d'un champ flexfield descriptif. Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données d'Oracle Fusion Financials

Étapes

Accéder à l'espace de travail Rapports et Analyses : Connectez-vous à Oracle Fusion Financials. Utilisez le menu Navigateur pour accéder à Outils, puis sélectionnez Rapports et Analyses. C'est le centre névralgique pour la création et la gestion de toutes les analyses et rapports.
Créer un modèle de données BI Publisher : Plutôt que de commencer par une analyse OTBI, il est plus efficace pour ce type d'extraction de journal d'événements de créer directement un modèle de données BI Publisher. Cela vous permet d'utiliser une requête SQL personnalisée avec des instructions UNION ALL. Cliquez sur le bouton 'Parcourir le catalogue', naviguez jusqu'à un dossier approprié et choisissez Créer > Modèle de données.
Définir l'ensemble de données de la requête SQL : Dans l'éditeur de modèle de données, cliquez sur l'icône '+' pour ajouter un nouvel ensemble de données et sélectionnez 'Requête SQL'. Donnez un nom descriptif à l'ensemble de données, par exemple, 'JournalEventLog'.
Saisir la requête SQL : Sélectionnez 'Oracle BI EE' comme source de données. Copiez le script SQL complet de la section Requête ci-dessous et collez-le dans la zone de texte Requête SQL. La requête est conçue pour extraire toutes les activités et attributs requis dans une structure unifiée unique.
Définir les paramètres : La requête fournie utilise des paramètres tels que :start_date, :end_date et :ledger_name. L'interface du modèle de données les détectera automatiquement. Vous devez les configurer comme des paramètres, en définissant les types de données appropriés (Date ou Texte) et les valeurs par défaut si nécessaire. Cela permet une exécution flexible du rapport.
Créer un rapport à partir du modèle de données : Après avoir enregistré le modèle de données, revenez au catalogue. Cliquez sur Créer > Rapport. Dans l'assistant de création de rapport, sélectionnez 'Utiliser le modèle de données existant' et localisez le modèle de données que vous venez de créer.
Configurer la mise en page du rapport : Dans l'éditeur de mise en page, choisissez la mise en page 'Tableau'. Il est crucial de faire glisser et déposer toutes les colonnes du modèle de données dans le tableau pour s'assurer qu'elles sont incluses dans l'exportation. Il n'y a pas besoin de formatage complexe.
Définir la sortie par défaut en CSV : Accédez au lien 'Afficher une liste' dans l'éditeur de rapport. Dans la section 'Formats de sortie', assurez-vous que 'CSV' est sélectionné. Il est recommandé de décocher tous les autres formats pour simplifier la planification. Enregistrez le rapport.
Planifier le rapport pour une extraction automatisée : Trouvez votre rapport enregistré dans le catalogue et cliquez sur 'Plus', puis sur 'Planifier'. Créez une nouvelle tâche planifiée. Configurez la fréquence, par exemple, quotidienne ou hebdomadaire.
Configurer l'exportation et la livraison : Dans l'onglet 'Sortie' de la tâche de planification, spécifiez les détails de la sortie. Sélectionnez votre rapport et choisissez 'CSV' comme format. Dans l'onglet 'Destination', vous pouvez configurer la livraison du fichier vers un emplacement de serveur de contenu (UCM) ou un serveur SFTP externe pour une récupération automatisée.
Récupérer et préparer les données : Une fois la tâche planifiée exécutée, récupérez le fichier CSV généré à partir de votre destination configurée. Assurez-vous que les en-têtes de colonne correspondent aux exigences d'ingestion de ProcessMind : JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. Le fichier est maintenant prêt pour le téléchargement.

Configuration

Source de données : La requête doit être exécutée sur la source de données 'Oracle BI EE' au sein de BI Publisher, qui se connecte aux vues de la base de données transactionnelle sous-jacente supportant OTBI.
Domaines thématiques clés (pour référence) : La logique de la requête est basée sur des données principalement trouvées dans le domaine thématique 'General Ledger - Journals Real Time'. Elle joint également logiquement des données qui se trouveraient dans 'HCM - Workforce Management - Worker Assignment Real Time' pour les détails des utilisateurs et potentiellement des domaines thématiques de workflow pour l'historique des approbations.
Filtrage par plage de dates : Il est essentiel de filtrer les données sur une période gérable. La requête inclut les paramètres :start_date et :end_date. Nous recommandons d'extraire 3 à 6 mois de données pour une analyse initiale. Le filtre est appliqué à la date de création de l'écriture comptable.
Filtrage par grand livre : Utilisez le paramètre :ledger_name pour limiter l'extraction à un grand livre principal spécifique. L'extraction de tous les grands livres en une seule fois peut entraîner des fichiers extrêmement volumineux et des problèmes de performance.
Prérequis : L'utilisateur créant et planifiant le rapport doit disposer des rôles BI appropriés, tels que 'BI Administrator' ou 'BI Author'. De plus, le profil de sécurité des données de l'utilisateur doit accorder l'accès aux grands livres et unités commerciales spécifiques interrogés.
Planification : Pour des performances optimales et pour éviter d'impacter les utilisateurs du système, planifiez l'exécution de la tâche d'extraction pendant les heures creuses, par exemple la nuit.

a Exemple de requête config

WITH JournalHeaders AS (
    SELECT
        gjh.je_header_id,
        gjh.ledger_id,
        gl.name AS ledger_name,
        gjb.je_batch_id,
        gjh.doc_sequence_value,
        gjh.name AS journal_name,
        gjc.user_je_category_name AS journal_category,
        gjs.user_je_source_name AS journal_source,
        gjh.default_effective_date,
        gjh.creation_date,
        gjh.created_by,
        gjh.last_update_date,
        gjh.last_updated_by,
        gjh.posted_date,
        gjb.approval_status_code AS batch_approval_status,
        gjh.accrual_rev_period_name,
        gjh.accrual_rev_je_header_id,
        (SELECT SUM(accounted_dr) FROM gl_je_lines WHERE je_header_id = gjh.je_header_id) AS journal_amount
    FROM
        gl_je_headers gjh
    JOIN
        gl_je_batches gjb ON gjh.je_batch_id = gjb.je_batch_id
    JOIN
        gl_ledgers gl ON gjh.ledger_id = gl.ledger_id
    JOIN
        gl_je_categories_tl gjc ON gjh.je_category = gjc.je_category_name AND gjc.language = USERENV('LANG')
    JOIN
        gl_je_sources_tl gjs ON gjh.je_source = gjs.je_source_name AND gjs.language = USERENV('LANG')
    WHERE
        gjh.creation_date BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND gl.name = :ledger_name
)
-- 1. Journal Entry Created
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment", -- Placeholder: Configure based on your department tracking
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(SYSDATE) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    fnd_attached_documents fad
JOIN
    JournalHeaders jh ON fad.pk1_value = TO_CHAR(jh.je_header_id) AND fad.entity_name = 'GL_JE_HEADERS'
LEFT JOIN
    per_users u ON fad.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(fad.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_transactions wft ON wft.transaction_id = jh.je_batch_id AND wft.application_id = 101 AND wft.transaction_class = 'Journal Batch'
JOIN
    fun_all_wf_approvals wfa ON wft.transaction_id = wfa.transaction_id AND wfa.response = 'SUBMITTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 4. Journal Entry Reviewed & 7. Journal Entry Approved
SELECT
    jh.je_header_id AS "JournalEntryId",
    CASE
        WHEN wfa.approval_level < (SELECT MAX(approval_level) FROM fun_all_wf_approvals WHERE transaction_id = wfa.transaction_id) THEN 'Journal Entry Reviewed'
        ELSE 'Journal Entry Approved'
    END AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'APPROVED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    wfa.reason AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'REJECTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 6. Journal Corrected and Resubmitted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    resubmit_events.created_date AS "EventTime",
    resubmit_events.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN (
    SELECT wfa.transaction_id, wfa.created_date, wfa.updated_by
    FROM fun_all_wf_approvals wfa
    WHERE wfa.response = 'SUBMITTED'
    AND EXISTS (
        SELECT 1
        FROM fun_all_wf_approvals prev_wfa
        WHERE prev_wfa.transaction_id = wfa.transaction_id
        AND prev_wfa.response = 'REJECTED'
        AND prev_wfa.created_date < wfa.created_date
    )
) resubmit_events ON jh.je_batch_id = resubmit_events.transaction_id
LEFT JOIN
    per_users u ON resubmit_events.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(resubmit_events.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 8. Journal Posting Initiated
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    gjb.last_update_date AS "EventTime",
    gjb.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_batches gjb ON jh.je_batch_id = gjb.je_batch_id
WHERE
    gjb.status = 'I' -- 'I' typically means Selected for Posting
    AND jh.posted_date IS NOT NULL
LEFT JOIN
    per_users u ON gjb.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(gjb.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.posted_date AS "EventTime",
    jh.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(jh.posted_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.posted_date IS NOT NULL

UNION ALL

-- 10. Posting Verified - This is a placeholder as it is typically a manual control step not logged in a standard table.
-- This part of the query will return no rows unless you have a custom solution, such as a Descriptive Flexfield (DFF), to track this.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Posting Verified' AS "ActivityName",
    jh.last_update_date AS "EventTime", -- Placeholder timestamp
    jh.last_updated_by AS "UserName", -- Placeholder user
    NULL AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
WHERE
    1 = 2 -- This condition ensures no rows are returned. Replace with logic for your custom DFF or tracking field.

UNION ALL

-- 11. Journal Entry Reconciled - This depends on integration with Oracle Account Reconciliation (ARCS).
-- This query assumes reconciliation status is written back to GL_RECONCILIATION_REFERENCES.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Reconciled' AS "ActivityName",
    grr.last_update_date AS "EventTime",
    grr.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_lines gjl ON jh.je_header_id = gjl.je_header_id
JOIN
    gl_reconciliation_references grr ON gjl.je_header_id = grr.je_header_id AND gjl.je_line_num = grr.je_line_num
WHERE
    grr.status = 'R' -- Assuming 'R' means Reconciled. Verify based on your ARCS configuration.
LEFT JOIN
    per_users u ON grr.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(grr.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.creation_date AS "EventTime",
    rev_jh.created_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_headers rev_jh ON jh.je_header_id = rev_jh.accrual_rev_je_header_id
LEFT JOIN
    per_users u ON rev_jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(rev_jh.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.accrual_rev_je_header_id IS NOT NULL

Étapes

Accéder à BI Publisher : Connectez-vous à Oracle Fusion Financials. Utilisez le menu Navigateur pour accéder à Outils, puis sélectionnez Rapports et Analyses. Cela ouvrira le catalogue Business Intelligence.
Créer un nouveau modèle de données : Dans le catalogue BI, cliquez sur le bouton Créer et sélectionnez Modèle de données. Cela ouvrira l'éditeur de modèle de données.
Définir l'ensemble de données de la requête SQL : Dans l'éditeur de modèle de données, cliquez sur l'icône plus dans l'onglet Diagramme et sélectionnez Requête SQL. Dans la nouvelle boîte de dialogue, donnez un nom à l'ensemble de données, par exemple, ProcessMind_JE_EventLog. Sélectionnez la source de données appropriée, qui est généralement FUSIONDB. Collez la requête SQL complète fournie dans la zone de texte Requête SQL.
Définir les paramètres : La requête utilise des paramètres pour la plage de dates (p_start_date et p_end_date). Oracle BI Publisher les détectera automatiquement. Vous devez les configurer comme paramètres de type Texte et définir des étiquettes conviviales comme 'Date de début (AAAA-MM-JJ)' et 'Date de fin (AAAA-MM-JJ)'.
Enregistrer le modèle de données : Après avoir collé la requête et défini les paramètres, cliquez sur OK et enregistrez le modèle de données dans un dossier approprié, par exemple, Dossiers partagés/Personnalisé/ProcessMining.
Créer le rapport : Cliquez sur le bouton Créer un rapport dans le coin supérieur droit de l'éditeur de modèle de données. L'assistant de création de rapport se lancera.
Configurer la mise en page du rapport : Dans l'assistant, sélectionnez l'option d'utiliser le modèle de données actuel. Choisissez la mise en page 'Tableau'. Faites glisser et déposez toutes les colonnes de la source de données dans la zone de mise en page du tableau. Décochez l'option 'Afficher la ligne des totaux'.
Enregistrer le rapport : Enregistrez le rapport dans le même dossier que le modèle de données. Donnez-lui un nom descriptif comme 'Rapport de journal d'événements des écritures comptables'.
Définir le format de sortie par défaut : Modifiez le rapport et accédez à l'onglet 'Affichage'. Sous 'Formats de sortie', assurez-vous que CSV est sélectionné et, de préférence, définissez-le comme format par défaut. Cela garantit que la sortie est compatible pour une utilisation directe.
Exécuter et exporter : Ouvrez le rapport et vous serez invité à saisir les paramètres de date de début et de fin. Saisissez la plage de dates souhaitée et cliquez sur Appliquer. Une fois le rapport exécuté, cliquez sur le bouton Exporter et choisissez le format CSV pour télécharger le fichier journal d'événements.
Préparer le téléchargement : Ouvrez le fichier CSV téléchargé. Vérifiez que les en-têtes de colonne correspondent aux noms d'attributs attendus (JournalEntryId, ActivityName, EventTime, etc.) et que les données sont correctement formatées avant de les télécharger sur la plateforme ProcessMind.

Configuration

Prérequis : L'utilisateur exécutant le rapport doit disposer d'un rôle avec les privilèges de sécurité des données nécessaires pour accéder aux données du grand livre général, tel que Comptable général ou un rôle BI personnalisé. L'accès à l'outil BI Publisher est également requis.
Source de données : Le modèle de données BI Publisher doit être configuré pour utiliser la connexion de base de données de l'application FUSIONDB.
Paramètres de plage de dates : La requête est conçue avec les paramètres p_start_date et p_end_date pour contrôler la fenêtre d'extraction des données. Il est recommandé de commencer avec une période de 3 à 6 mois de données pour garantir les performances.
Filtres de rapport : Pour les grandes organisations, il est fortement recommandé d'ajouter des filtres directement dans la clause WHERE de l'expression de table commune JournalHeaders de la requête. Le filtrage par LEDGER_ID ou LEGAL_ENTITY_ID est essentiel pour gérer le volume de données.
Considérations de performance : L'exécution de cette requête sur une grande base de données de production peut consommer des ressources importantes. Planifiez l'exécution du rapport pendant les heures creuses afin de minimiser l'impact sur les performances du système.
Format de sortie : Le rapport doit être configuré pour générer un fichier CSV. Cela fournit un format propre et structuré pour l'ingestion dans les outils de process mining.

a Exemple de requête sql

WITH JournalHeaders AS (
    SELECT
        gjh.JE_HEADER_ID,
        gjh.NAME AS JOURNAL_NAME,
        gjh.LEDGER_ID,
        gjh.JE_CATEGORY,
        gjh.JE_SOURCE,
        gjh.STATUS,
        gjh.APPROVAL_STATUS_CODE,
        gjh.CREATED_BY,
        gjh.CREATION_DATE,
        gjh.LAST_UPDATED_BY,
        gjh.LAST_UPDATE_DATE,
        gjh.POSTED_DATE,
        gjh.ACCRUAL_REV_JE_HEADER_ID,
        gjh.ACCRUAL_REV_PERIOD_NAME,
        gjs.USER_JE_SOURCE_NAME,
        gjc.USER_JE_CATEGORY_NAME,
        (SELECT SUM(NVL(gjl.ACCOUNTED_DR, 0)) FROM GL_JE_LINES gjl WHERE gjl.JE_HEADER_ID = gjh.JE_HEADER_ID) AS JOURNAL_AMOUNT
    FROM
        GL_JE_HEADERS gjh
    JOIN
        GL_JE_SOURCES_TL gjs ON gjh.JE_SOURCE = gjs.JE_SOURCE_NAME AND gjs.LANGUAGE = USERENV('LANG')
    JOIN
        GL_JE_CATEGORIES_TL gjc ON gjh.JE_CATEGORY = gjc.JE_CATEGORY_NAME AND gjc.LANGUAGE = USERENV('LANG')
    WHERE
        gjh.CREATION_DATE BETWEEN TO_TIMESTAMP(:p_start_date || ' 00:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF') AND TO_TIMESTAMP(:p_end_date || ' 23:59:59.999', 'YYYY-MM-DD HH24:MI:SS.FF')
        AND gjh.ACTUAL_FLAG = 'A'
        -- Recommended: Add a filter for your specific ledger(s) to improve performance
        -- AND gjh.LEDGER_ID IN ([Your Ledger ID])
),
UserDepartment AS (
    -- This subquery is an example. The join logic to find a user's department may need to be adjusted
    -- based on your specific Oracle HCM configuration (e.g., using different assignment types or tables).
    SELECT 
        pu.USERNAME, 
        org.NAME as Department
    FROM PER_USERS pu
    LEFT JOIN PER_ALL_ASSIGNMENTS_F asg ON pu.PERSON_ID = asg.PERSON_ID 
        AND asg.ASSIGNMENT_TYPE IN ('E', 'C') 
        AND asg.PRIMARY_FLAG = 'Y'
        AND SYSDATE BETWEEN asg.EFFECTIVE_START_DATE AND asg.EFFECTIVE_END_DATE
    LEFT JOIN HR_ALL_ORGANIZATION_UNITS_F_VL org ON asg.ORGANIZATION_ID = org.ORGANIZATION_ID
        AND SYSDATE BETWEEN org.EFFECTIVE_START_DATE AND org.EFFECTIVE_END_DATE
    WHERE pu.USERNAME IS NOT NULL
)
-- 1. Journal Entry Created
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.CREATED_BY = ud.USERNAME

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    TO_NUMBER(fad.PK1_VALUE) AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    fad.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    FND_ATTACHED_DOCUMENTS fad
JOIN
    JournalHeaders jh ON fad.PK1_VALUE = TO_CHAR(jh.JE_HEADER_ID)
LEFT JOIN UserDepartment ud ON fad.CREATED_BY = ud.USERNAME
WHERE
    fad.ENTITY_NAME = 'GL_JE_HEADERS'

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE IN ('REQUIRED', 'INITIATED')

UNION ALL

-- 4. Journal Entry Reviewed (Placeholder)
-- This activity requires custom logic based on your approval workflow configuration.
-- The query below is a placeholder and may not return any data without customization.
-- It assumes a review happens if the approval status is updated but not yet approved or rejected.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    -- Rejection Reason is not a standard field. This might be found in workflow tables.
    '[Configure based on your system]' AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE = 'REJECTED'

UNION ALL

-- 6. Journal Corrected and Resubmitted
-- This logic assumes a resubmission is an update that occurs after a rejection.
-- A more precise method would involve analyzing workflow history, which is complex.
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE IN ('REQUIRED', 'INITIATED')
    AND jh.JE_HEADER_ID IN (SELECT h.JE_HEADER_ID FROM GL_JE_HEADERS h WHERE h.APPROVAL_STATUS_CODE = 'REJECTED')

UNION ALL

-- 7. Journal Entry Approved
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Approved' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE = 'APPROVED'

UNION ALL

-- 8. Journal Posting Initiated
-- The exact initiation time is not stored. We infer it as 5 minutes before the final posted date.
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    (jh.POSTED_DATE - INTERVAL '5' MINUTE) AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    -- Posting is often a system process, so user might not be available.
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.STATUS = 'P' AND jh.POSTED_DATE IS NOT NULL

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.POSTED_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.STATUS = 'P' AND jh.POSTED_DATE IS NOT NULL

UNION ALL

-- 10. Posting Verified (Placeholder)
-- This is a manual control activity not tracked by default. This query must be customized.
-- It assumes a descriptive flexfield named 'POSTING_VERIFIED_DATE' on GL_JE_HEADERS exists.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 11. Journal Entry Reconciled (Placeholder)
-- Reconciliation is typically done in other modules. This query must be customized.
-- It assumes a custom table or field indicates when a journal is reconciled.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.POSTED_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    rev_jh.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
JOIN
    GL_JE_HEADERS rev_jh ON jh.ACCRUAL_REV_JE_HEADER_ID = rev_jh.JE_HEADER_ID
LEFT JOIN UserDepartment ud ON rev_jh.CREATED_BY = ud.USERNAME
WHERE
    jh.ACCRUAL_REV_JE_HEADER_ID IS NOT NULL
    AND rev_jh.STATUS = 'P'
ORDER BY
    "JournalEntryId", "EventTime"

Étapes

Prérequis : Assurez-vous d'avoir Python 3 installé ainsi que les bibliothèques requests et pandas. Vous aurez besoin d'un compte utilisateur pour Oracle Fusion Financials avec les permissions nécessaires pour accéder à l'API REST des Journaux du Grand Livre Général. Obtenez l'URL de votre instance Oracle Fusion, votre nom d'utilisateur et votre mot de passe.
Configuration du script : Créez un nouveau fichier de script Python. Commencez par importer les bibliothèques nécessaires : requests, json, pandas et datetime.
Configuration : Dans le script, définissez les variables pour vos identifiants Oracle Fusion et l'URL de base. Définissez également les paramètres pour l'extraction des données, tels que les dates de début et de fin pour la requête.
Authentification : Le script utilise l'authentification de base. La bibliothèque requests gère l'encodage du nom d'utilisateur et du mot de passe dans les en-têtes de requête.
Définir la fonction d'appel API : Créez une fonction pour gérer les requêtes API. Cette fonction doit gérer la pagination en utilisant les paramètres offset et limit. Elle bouclera, effectuant des appels API successifs, jusqu'à ce que tous les enregistrements de journaux dans la plage de dates spécifiée aient été récupérés.
Construire la requête API : Utilisez le paramètre q dans la requête API pour filtrer les journaux en fonction de la LastUpdateDate. Cela permet une extraction ciblée des données dans un laps de temps spécifique, par exemple LastUpdateDate between '2023-01-01' and '2023-03-31'.
Lancer la récupération des données : Appelez la fonction pour commencer à récupérer les données depuis le point d'accès .../fscmRestApi/resources/11.13.18.05/journals. La fonction renverra une liste complète des écritures comptables.
Traiter et transformer les données : Parcourez chaque écriture comptable renvoyée par l'API. Pour chaque journal, générez plusieurs lignes d'événements correspondant aux différentes activités métier (Journal Entry Created, Journal Entry Approved, etc.). Utilisez les champs de date et les codes de statut de la réponse API (CreationDate, PostedDate, ApprovalStatus, etc.) pour créer ces événements distincts.
Structurer le journal d'événements : Au fur et à mesure que chaque ligne d'événement est générée, stockez-la sous forme de dictionnaire dans une liste. Cette liste deviendra les données brutes de votre journal d'événements.
Créer un DataFrame : Une fois tous les journaux traités, convertissez la liste de dictionnaires d'événements en un DataFrame Pandas pour une manipulation plus facile.
Finaliser les colonnes : Sélectionnez et renommez les colonnes du DataFrame pour qu'elles correspondent au schéma requis pour ProcessMind : JournalEntryId, ActivityName, EventTime, UserName, etc.
Exporter en CSV : Enregistrez le DataFrame final dans un fichier CSV. Ce fichier peut ensuite être directement téléchargé sur ProcessMind pour analyse.

Configuration

Identifiants : Un nom d'utilisateur et un mot de passe Oracle Fusion valides sont requis pour l'authentification de base.
URL de l'instance : L'URL de base de votre instance Oracle Fusion Financials est nécessaire pour construire le point d'accès API (par exemple, https://[your-instance].fa.us2.oraclecloud.com).
Point d'accès API : Le script cible le point d'accès API fscmRestApi/resources/11.13.18.05/journals pour récupérer les données du grand livre général.
Filtre de plage de dates : Le script doit être configuré avec une start_date et une end_date pour limiter le périmètre d'extraction. Pour une analyse initiale, une période de 3 à 6 mois est recommandée. Pour une utilisation continue, configurez-le pour des chargements incrémentiels quotidiens ou hebdomadaires.
Limite de pagination : Le paramètre limit contrôle le nombre d'enregistrements récupérés par appel API. Une valeur entre 200 et 500 est généralement efficace, équilibrant le nombre d'appels API et la taille de chaque réponse.
Rôles Oracle requis : Le compte utilisateur doit avoir un rôle avec les privilèges nécessaires pour lire les données des écritures comptables via l'API REST, tel que Comptable général ou un rôle personnalisé avec des autorisations équivalentes.

a Exemple de requête python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance details
FUSION_URL = class="hl-string">"https://[your-instance].fa.us2.oraclecloud.com"
USERNAME = class="hl-string">"[your-username]"
PASSWORD = class="hl-string">"[your-password]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"
PAGE_LIMIT = 500 class=class="hl-string">"hl-comment"># Number of records per API call

def get_all_journals(base_url, user, password, start_date, end_date):
    class="hl-string">"""Fetches all journals from the Oracle Fusion REST API within a date range, handling pagination."""
    all_journals = []
    offset = 0
    has_more = True
    
    api_url = fclass="hl-string">"{base_url}/fscmRestApi/resources/11.13.18.05/journals"
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourcecollection+json'
    }
    
    query_filter = fclass="hl-string">"LastUpdateDate between '{start_date}' and '{end_date}'"
    
    while has_more:
        params = {
            class="hl-string">'q': query_filter,
            class="hl-string">'onlyData': class="hl-string">'true',
            class="hl-string">'limit': PAGE_LIMIT,
            class="hl-string">'offset': offset,
            class="hl-string">'fields': class="hl-string">'JeHeaderId,CreatedBy,CreationDate,LastUpdatedBy,LastUpdateDate,PostedDate,ApprovalStatus,ActualFlag,DefaultEffectiveDate,Description,JeCategory,JeSource,PeriodName,TotalDebit,ReversalDate,ReversalPeriodName,ExternalReference,attachments'
        }
        
        print(fclass="hl-string">"Fetching records from offset {offset}...")
        try:
            response = requests.get(api_url, auth=(user, password), headers=headers, params=params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            
            journals = data.get(class="hl-string">'items', [])
            all_journals.extend(journals)
            
            has_more = data.get(class="hl-string">'hasMore', False)
            offset += PAGE_LIMIT

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            has_more = False

    return all_journals

def transform_to_event_log(journals):
    class="hl-string">"""Transforms the raw journal data into a structured event log."""
    event_log = []
    extraction_timestamp = datetime.now(timezone.utc).isoformat()

    for jrnl in journals:
        journal_id = jrnl.get(class="hl-string">'JeHeaderId')
        created_by = jrnl.get(class="hl-string">'CreatedBy')
        last_updated_by = jrnl.get(class="hl-string">'LastUpdatedBy')
        approval_status = jrnl.get(class="hl-string">'ApprovalStatus')
        rejection_reason_text = class="hl-string">"Rejected per workflow comments" if approval_status == class="hl-string">'REJECTED' else None

        class=class="hl-string">"hl-comment"># 1. Journal Entry Created
        if jrnl.get(class="hl-string">'CreationDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Created',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'CreationDate'),
                class="hl-string">'UserName': created_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 2. Supporting Documentation Attached (Approximation)
        if jrnl.get(class="hl-string">'attachments') and len(jrnl[class="hl-string">'attachments']) > 0:
             event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Supporting Documentation Attached',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class=class="hl-string">"hl-comment"># Approximation: uses last update date
                class="hl-string">'UserName': last_updated_by, 
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 3, 4, 5, 6, 7: Approval Workflow Events (Inferred from final status)
        class=class="hl-string">"hl-comment"># Note: This block infers events. For a more detailed history, workflow-specific APIs would be needed.
        if approval_status in [class="hl-string">'IN_PROCESS', class="hl-string">'REQUIRED']:
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Submitted For Approval',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        elif approval_status == class="hl-string">'REJECTED':
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Rejected',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by, class=class="hl-string">"hl-comment"># Approver is often the last updater
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': rejection_reason_text,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            class=class="hl-string">"hl-comment"># A resubmission is assumed if a rejected journal is updated again
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Corrected and Resubmitted',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': created_by, class=class="hl-string">"hl-comment"># Typically the creator corrects it
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        elif approval_status == class="hl-string">'APPROVED':
            class=class="hl-string">"hl-comment"># class="hl-string">'Journal Entry Reviewed' is often an implicit part of approval
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reviewed',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Approved',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 8, 9: Posting Events
        if jrnl.get(class="hl-string">'PostedDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Posting Initiated',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'PostedDate'), class=class="hl-string">"hl-comment"># Assuming initiation is same as posted time
                class="hl-string">'UserName': class="hl-string">'System', class=class="hl-string">"hl-comment"># Posting is often a system process
                class="hl-string">'UserDepartment': class="hl-string">'Finance Operations', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Posted',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'PostedDate'),
                class="hl-string">'UserName': class="hl-string">'System',
                class="hl-string">'UserDepartment': class="hl-string">'Finance Operations', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        
        class=class="hl-string">"hl-comment"># 12. Journal Reversal Processed
        if jrnl.get(class="hl-string">'ReversalDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Reversal Processed',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'ReversalDate'),
                class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># Activities not directly available from this API, added as placeholders for potential enrichment
        class=class="hl-string">"hl-comment"># Posting Verified, Journal Entry Reconciled

    return pd.DataFrame(event_log)

class=class="hl-string">"hl-comment"># --- Main Execution ---
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Oracle Fusion Journal Entry extraction...")
    raw_journals = get_all_journals(FUSION_URL, USERNAME, PASSWORD, START_DATE, END_DATE)
    
    if raw_journals:
        print(fclass="hl-string">"Successfully extracted {len(raw_journals)} journal records.")
        event_log_df = transform_to_event_log(raw_journals)
        
        if not event_log_df.empty:
            class=class="hl-string">"hl-comment"># Save to CSV
            output_filename = fclass="hl-string">"oracle_fusion_journal_events_{START_DATE}_to_{END_DATE}.csv"
            event_log_df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"Event log saved to {output_filename}")
        else:
            print(class="hl-string">"No events were generated from the extracted data.")
    else:
        print(class="hl-string">"No data extracted. Please check configuration and API availability.")

Étapes

Accéder à l'espace de travail Rapports et Analyses : Connectez-vous à Oracle Fusion Financials. Utilisez le menu Navigateur pour accéder à Outils, puis sélectionnez Rapports et Analyses. C'est le centre névralgique pour la création et la gestion de toutes les analyses et rapports.
Créer un modèle de données BI Publisher : Plutôt que de commencer par une analyse OTBI, il est plus efficace pour ce type d'extraction de journal d'événements de créer directement un modèle de données BI Publisher. Cela vous permet d'utiliser une requête SQL personnalisée avec des instructions UNION ALL. Cliquez sur le bouton 'Parcourir le catalogue', naviguez jusqu'à un dossier approprié et choisissez Créer > Modèle de données.
Définir l'ensemble de données de la requête SQL : Dans l'éditeur de modèle de données, cliquez sur l'icône '+' pour ajouter un nouvel ensemble de données et sélectionnez 'Requête SQL'. Donnez un nom descriptif à l'ensemble de données, par exemple, 'JournalEventLog'.
Saisir la requête SQL : Sélectionnez 'Oracle BI EE' comme source de données. Copiez le script SQL complet de la section Requête ci-dessous et collez-le dans la zone de texte Requête SQL. La requête est conçue pour extraire toutes les activités et attributs requis dans une structure unifiée unique.
Définir les paramètres : La requête fournie utilise des paramètres tels que :start_date, :end_date et :ledger_name. L'interface du modèle de données les détectera automatiquement. Vous devez les configurer comme des paramètres, en définissant les types de données appropriés (Date ou Texte) et les valeurs par défaut si nécessaire. Cela permet une exécution flexible du rapport.
Créer un rapport à partir du modèle de données : Après avoir enregistré le modèle de données, revenez au catalogue. Cliquez sur Créer > Rapport. Dans l'assistant de création de rapport, sélectionnez 'Utiliser le modèle de données existant' et localisez le modèle de données que vous venez de créer.
Configurer la mise en page du rapport : Dans l'éditeur de mise en page, choisissez la mise en page 'Tableau'. Il est crucial de faire glisser et déposer toutes les colonnes du modèle de données dans le tableau pour s'assurer qu'elles sont incluses dans l'exportation. Il n'y a pas besoin de formatage complexe.
Définir la sortie par défaut en CSV : Accédez au lien 'Afficher une liste' dans l'éditeur de rapport. Dans la section 'Formats de sortie', assurez-vous que 'CSV' est sélectionné. Il est recommandé de décocher tous les autres formats pour simplifier la planification. Enregistrez le rapport.
Planifier le rapport pour une extraction automatisée : Trouvez votre rapport enregistré dans le catalogue et cliquez sur 'Plus', puis sur 'Planifier'. Créez une nouvelle tâche planifiée. Configurez la fréquence, par exemple, quotidienne ou hebdomadaire.
Configurer l'exportation et la livraison : Dans l'onglet 'Sortie' de la tâche de planification, spécifiez les détails de la sortie. Sélectionnez votre rapport et choisissez 'CSV' comme format. Dans l'onglet 'Destination', vous pouvez configurer la livraison du fichier vers un emplacement de serveur de contenu (UCM) ou un serveur SFTP externe pour une récupération automatisée.
Récupérer et préparer les données : Une fois la tâche planifiée exécutée, récupérez le fichier CSV généré à partir de votre destination configurée. Assurez-vous que les en-têtes de colonne correspondent aux exigences d'ingestion de ProcessMind : JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. Le fichier est maintenant prêt pour le téléchargement.

Configuration

Source de données : La requête doit être exécutée sur la source de données 'Oracle BI EE' au sein de BI Publisher, qui se connecte aux vues de la base de données transactionnelle sous-jacente supportant OTBI.
Domaines thématiques clés (pour référence) : La logique de la requête est basée sur des données principalement trouvées dans le domaine thématique 'General Ledger - Journals Real Time'. Elle joint également logiquement des données qui se trouveraient dans 'HCM - Workforce Management - Worker Assignment Real Time' pour les détails des utilisateurs et potentiellement des domaines thématiques de workflow pour l'historique des approbations.
Filtrage par plage de dates : Il est essentiel de filtrer les données sur une période gérable. La requête inclut les paramètres :start_date et :end_date. Nous recommandons d'extraire 3 à 6 mois de données pour une analyse initiale. Le filtre est appliqué à la date de création de l'écriture comptable.
Filtrage par grand livre : Utilisez le paramètre :ledger_name pour limiter l'extraction à un grand livre principal spécifique. L'extraction de tous les grands livres en une seule fois peut entraîner des fichiers extrêmement volumineux et des problèmes de performance.
Prérequis : L'utilisateur créant et planifiant le rapport doit disposer des rôles BI appropriés, tels que 'BI Administrator' ou 'BI Author'. De plus, le profil de sécurité des données de l'utilisateur doit accorder l'accès aux grands livres et unités commerciales spécifiques interrogés.
Planification : Pour des performances optimales et pour éviter d'impacter les utilisateurs du système, planifiez l'exécution de la tâche d'extraction pendant les heures creuses, par exemple la nuit.

a Exemple de requête config

WITH JournalHeaders AS (
    SELECT
        gjh.je_header_id,
        gjh.ledger_id,
        gl.name AS ledger_name,
        gjb.je_batch_id,
        gjh.doc_sequence_value,
        gjh.name AS journal_name,
        gjc.user_je_category_name AS journal_category,
        gjs.user_je_source_name AS journal_source,
        gjh.default_effective_date,
        gjh.creation_date,
        gjh.created_by,
        gjh.last_update_date,
        gjh.last_updated_by,
        gjh.posted_date,
        gjb.approval_status_code AS batch_approval_status,
        gjh.accrual_rev_period_name,
        gjh.accrual_rev_je_header_id,
        (SELECT SUM(accounted_dr) FROM gl_je_lines WHERE je_header_id = gjh.je_header_id) AS journal_amount
    FROM
        gl_je_headers gjh
    JOIN
        gl_je_batches gjb ON gjh.je_batch_id = gjb.je_batch_id
    JOIN
        gl_ledgers gl ON gjh.ledger_id = gl.ledger_id
    JOIN
        gl_je_categories_tl gjc ON gjh.je_category = gjc.je_category_name AND gjc.language = USERENV('LANG')
    JOIN
        gl_je_sources_tl gjs ON gjh.je_source = gjs.je_source_name AND gjs.language = USERENV('LANG')
    WHERE
        gjh.creation_date BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND gl.name = :ledger_name
)
-- 1. Journal Entry Created
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment", -- Placeholder: Configure based on your department tracking
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(SYSDATE) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    fnd_attached_documents fad
JOIN
    JournalHeaders jh ON fad.pk1_value = TO_CHAR(jh.je_header_id) AND fad.entity_name = 'GL_JE_HEADERS'
LEFT JOIN
    per_users u ON fad.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(fad.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_transactions wft ON wft.transaction_id = jh.je_batch_id AND wft.application_id = 101 AND wft.transaction_class = 'Journal Batch'
JOIN
    fun_all_wf_approvals wfa ON wft.transaction_id = wfa.transaction_id AND wfa.response = 'SUBMITTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 4. Journal Entry Reviewed & 7. Journal Entry Approved
SELECT
    jh.je_header_id AS "JournalEntryId",
    CASE
        WHEN wfa.approval_level < (SELECT MAX(approval_level) FROM fun_all_wf_approvals WHERE transaction_id = wfa.transaction_id) THEN 'Journal Entry Reviewed'
        ELSE 'Journal Entry Approved'
    END AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'APPROVED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    wfa.reason AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'REJECTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 6. Journal Corrected and Resubmitted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    resubmit_events.created_date AS "EventTime",
    resubmit_events.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN (
    SELECT wfa.transaction_id, wfa.created_date, wfa.updated_by
    FROM fun_all_wf_approvals wfa
    WHERE wfa.response = 'SUBMITTED'
    AND EXISTS (
        SELECT 1
        FROM fun_all_wf_approvals prev_wfa
        WHERE prev_wfa.transaction_id = wfa.transaction_id
        AND prev_wfa.response = 'REJECTED'
        AND prev_wfa.created_date < wfa.created_date
    )
) resubmit_events ON jh.je_batch_id = resubmit_events.transaction_id
LEFT JOIN
    per_users u ON resubmit_events.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(resubmit_events.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 8. Journal Posting Initiated
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    gjb.last_update_date AS "EventTime",
    gjb.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_batches gjb ON jh.je_batch_id = gjb.je_batch_id
WHERE
    gjb.status = 'I' -- 'I' typically means Selected for Posting
    AND jh.posted_date IS NOT NULL
LEFT JOIN
    per_users u ON gjb.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(gjb.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.posted_date AS "EventTime",
    jh.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(jh.posted_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.posted_date IS NOT NULL

UNION ALL

-- 10. Posting Verified - This is a placeholder as it is typically a manual control step not logged in a standard table.
-- This part of the query will return no rows unless you have a custom solution, such as a Descriptive Flexfield (DFF), to track this.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Posting Verified' AS "ActivityName",
    jh.last_update_date AS "EventTime", -- Placeholder timestamp
    jh.last_updated_by AS "UserName", -- Placeholder user
    NULL AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
WHERE
    1 = 2 -- This condition ensures no rows are returned. Replace with logic for your custom DFF or tracking field.

UNION ALL

-- 11. Journal Entry Reconciled - This depends on integration with Oracle Account Reconciliation (ARCS).
-- This query assumes reconciliation status is written back to GL_RECONCILIATION_REFERENCES.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Reconciled' AS "ActivityName",
    grr.last_update_date AS "EventTime",
    grr.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_lines gjl ON jh.je_header_id = gjl.je_header_id
JOIN
    gl_reconciliation_references grr ON gjl.je_header_id = grr.je_header_id AND gjl.je_line_num = grr.je_line_num
WHERE
    grr.status = 'R' -- Assuming 'R' means Reconciled. Verify based on your ARCS configuration.
LEFT JOIN
    per_users u ON grr.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(grr.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.creation_date AS "EventTime",
    rev_jh.created_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_headers rev_jh ON jh.je_header_id = rev_jh.accrual_rev_je_header_id
LEFT JOIN
    per_users u ON rev_jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(rev_jh.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.accrual_rev_je_header_id IS NOT NULL

Votre modèle de données Record to Report - Écriture comptable

Votre modèle de données Record to Report - Écriture comptable

Record to Report - Attributs des écritures comptables

Record to Report - Activités des écritures comptables

Guides d'extraction

Exportation de rapports Oracle OTBI et BI Publisher

Étapes

Configuration

a Exemple de requête config

Rapport BI Publisher avec requête SQL directe sur le modèle de données

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l'API REST Oracle Fusion Financials

Étapes

Configuration

a Exemple de requête python

Extraction de données en masse à l'aide de BI Cloud Connector (BICC)

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Accélérez votre processus Record to Report - Saisie des écritures comptables dès aujourd'hui

Votre modèle de données Record to Report - Écriture comptable

Votre modèle de données Record to Report - Écriture comptable

Record to Report - Attributs des écritures comptables

Record to Report - Activités des écritures comptables

Guides d'extraction

Exportation de rapports Oracle OTBI et BI Publisher

Étapes

Configuration

a Exemple de requête config

Rapport BI Publisher avec requête SQL directe sur le modèle de données

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l'API REST Oracle Fusion Financials

Étapes

Configuration

a Exemple de requête python

Extraction de données en masse à l'aide de BI Cloud Connector (BICC)

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Accélérez votre processus Record to Report - Saisie des écritures comptables dès aujourd'hui