> Amélioration Continue des Processusus > Comptabilité et Reporting Écritures comptables > Oracle Fusion Financials > Template de données

Votre modèle de données pour la Comptabilité et Reporting - Écritures comptables

Oracle Fusion Financials

← Retour au Guide d'amélioration

Comptabilité et Reporting - Attributs des écritures comptables. (21) Comptabilité et Reporting - Activités des écritures comptables. (12) Guides d'extraction (4)

Votre modèle de données pour la Comptabilité et Reporting - Écritures comptables

Ce modèle de données fournit un guide détaillé 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 fiable. 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

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

Télécharger le modèle

Comptabilité et Reporting - 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 Clôture et rapports financiers (Du Grand Livre au rapport) - Écritures comptables.

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Descriptionn
	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.
Descriptionn 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 essentielles 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 reprise. 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 est-ce important ? : Il définit les étapes du processus, constituant l'pilier central de la carte de processus et permettant l'analyse du flux, des points de blocage et des variations. Source des données : 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 Comptable Soumise pour ApprobationÉcriture de journal approuvéeÉcriture de journal comptabilisée
	Heure de début EventTime	L'horodatage indiquant quand une activité ou un événement spécifique s'est produit.
Descriptionn 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 indispensable pour toutes les analyses temporelles, y compris le calcul des temps de cycle, l'identification des points de blocage et le suivi des performances par rapport aux accords de niveau de service. Elle fournit l'ordre chronologique nécessaire pour reconstituer le flux de processus tel qu'il s'est produit. Pourquoi est-ce important ? : Cet horodatage est indispensable pour ordonner les événements, calculer toutes les durées de processus et effectuer toute analyse basée sur le temps. Source des données : 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 de l'écriture comptable JournalEntryId	L'identifiant unique pour une seule écriture comptable, liant toutes les activités de transaction financière associées.
Descriptionn L'ID d'écriture comptable sert d'identifiant de dossier 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 indispensable pour reconstituer le parcours complet 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 points de blocage et des variations de processus. Pourquoi est-ce important ? : Ceci est la clé clée pour suivre une écriture comptable complet, permettant d'analyser l'ensemble du flux de processus pour chaque cas unique. Source des données : 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	L'horodatage de la dernière actualisation des données ou de l'extraction du système source.
Descriptionn Cet attribut enregistre la dernière mise à jour de l'ensemble de données. Il fournit un contexte sur la la réactualisation 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 dashboards opérationnels, connaître l'heure de la dernière mise à jour des données est indispensable 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 est-ce important ? : Indique la la réactualisation des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse des processus et peuvent faire confiance aux analyses. Source des données : Cette valeur est générée et stockée pendant le processus d'extraction et de transformation des données. Il s'agit généralement de 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.
Descriptionn Cet attribut identifie le système source d'où les données de processus ont été extraites. Dans un environnement 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 impératif 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 est-ce important ? : Identifie l'origine des données, ce qui est impératif pour la gouvernance des données, la validation et la compréhension des variations de processus entre différents systèmes. Source des données : 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 de l'Écriture Comptable JournalCategory	La catégorie de l'écriture comptable, telle que 'Charge à payer', 'Ajustement' ou 'Reclassification'.
Descriptionn La catégorie d'écriture classe les écritures en fonction de leur objectif métier. Cette classification permet une analyse plus granulairesre 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 est-ce 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. Source des données : Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé JE_CATEGORY. Exemples ProvisionManuelAjustementRéévaluation
	Département de l'utilisateur UserDepartment	Le département ou l'équipe auquel appartient l'utilisateur qui a effectué l'activité.
Descriptionn 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 points de blocage interdépartementaux, à comparer la performance des équipes et à comprendre comment l'exécution des processus diffère dans l'organisation. Elle est précieuse pour l'allocation des ressources et les initiatives d'amélioration des processus ciblées. Pourquoi est-ce important ? : Fournit un contexte organisationnel, permettant une analyse des performances par équipe ou département et mettant en évidence les inefficacités interfonctionnelles. Source des données : 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 du journal JournalAmount	La valeur monétaire totale de l'écriture de journal, généralement la somme des débits.
Descriptionn 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 est-ce 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. Source des données : 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.
Descriptionn 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élèvement.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 est-ce important ? : Offre un aperçu direct des causes profondes du reprises et des retards de processus, permettant des améliorations ciblées pour réduire les taux de rejet. Source des données : 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 Comptable JournalSource	Le grand livre auxiliaire ou la source qui a généré l'écriture comptable, tels que 'Comptes fournisseurs', 'Comptes clients' ou 'Manuel'.
Descriptionn 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 est-ce important ? : Distingue les saisies manuelles des saisies automatisées, ce qui est indispensable pour mesurer les taux d'automatisation et analyser les différences de processus. Source des données : 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.
Descriptionn Cet attribut identifie l'employé ou l'utilisateur système spécifique responsable de l'exécution d'une activité. Il est impératif pour comprendre la répartition de la charge de travail, la performance et l'identification des points de blocage 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 dashboards comme 'Charge de travail et efficacité des utilisateurs par équipe' et les KPI comme 'Indice de goulot d'étranglement des écritures par utilisateur'. Pourquoi est-ce 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. Source des données : 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.
Descriptionn 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 indispensable 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 est-ce 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. Source des données : 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.
Descriptionn Le Code de devise spécifie la devise des montants financiers de l'écriture comptable. Ceci est indispensable 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 est-ce 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. Source des données : Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé CURRENCY_CODE. Exemples USDEURGBPJPY
	Est un reprises IsRework	Un indicateur calculé qui est vrai si l'écriture comptable a subi un cycle de rejet et de correction.
Descriptionn Cet attribut booléen est calculé pour identifier les cases ayant fait l'objet d'un reprises. 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 reprise. Il alimente directement le KPI « Average Journal Rework Rate » et facilite la comparaison du flux et de la durée des cases avec reprises par rapport à ceux traités correctement dès la première fois. Pourquoi est-ce important ? : Signale directement les cas ayant traversé des boucles de reprise inefficaces, facilitant la quantification de la fréquence et de l'impact des échecs de processus. Source des données : Ceci n'est pas disponible dans le système source. Il est calculé dans 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.
Descriptionn L'Heure de fin marque la fin 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 indispensable pour calculer les temps de traitement des activités, qui est une métrique clé pour identifier les points de blocage 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 est-ce important ? : Il permet le calcul de la durée réelle ou du temps de traitement des activités individuelles, ce qui est indispensable pour identifier les problèmes d'efficacité. Source des données : 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.
Descriptionn 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 indispensablele 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 est-ce 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. Source des données : 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.
Descriptionn 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 indispensable 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 est-ce important ? : Permet de filtrer et de comparer l'analyse des processus entre différentes entités juridiques ou cadres comptables, ce qui est indispensable à les grandes organisations. Source des données : 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'.
Descriptionn La Période comptable spécifie la période financière au cours de laquelle la transaction est reconnue. Ceci est indispensable pour tous les rapports et analyses financiers. En Process Mining, cet attribut est impératif 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 est-ce 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. Source des données : Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé PERIOD_NAME. Exemples Janv-24Fév-24Mars-24
	Statut de Comptabilisation PostingStatus	Le statut de comptabilisation actuel de l'écriture comptable, par exemple, 'Non comptabilisée' ou 'Comptabilisée'.
Descriptionn 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 impératif pour le tableau de bord '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 est-ce important ? : Indique l'état actuel d'une écriture comptable, ce qui est indispensable pour surveiller les arriérés et suivre le statut des écritures en cours. Source des données : Disponible dans la table GL_JE_HEADERS, généralement dans une colonne comme STATUS ou POSTING_STATUS. Exemples ComptabiliséNon comptabiliséeErreur
	Temps de cycle complet EndToEndCycleTime	La durée totale calculée entre la création d'une écriture comptable et son rapprochement final.
Descriptionn 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 d'ensemble complète de la performance du processus. Ceci est un KPI primaire pour mesurer l'efficacité globale du processus. Il est utilisé dans les dashboards 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 est-ce 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. Source des données : 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.
Descriptionn Cet attribut booléen est obtenu en comparant l'horodatage 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 contribue directement au 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 est-ce 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. Source des données : 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

Comptabilité et Reporting - 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é	Descriptionn
	Écriture Comptable Soumise pour Approbation	Cette activité se produit lorsque l'utilisateur soumet formellement l'écriture comptable terminé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 est-ce important ? : Ceci est un jalon critique qui lance le décompte pour mesurer les temps de cycle d'approbation et identifier les points de blocage. Il sépare la phase de saisie des données de la phase d'examen et d'approbation. Source des données : 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
	Écriture de journal 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 est-ce 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 points de blocage d'approbation. Source des données : 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 de journal comptabilisé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 est-ce important ? : Ceci est un jalon critique représentant l'entrée de l'écriture dans le registre financier officiel. Il est indispensable pour mesurer le taux de comptabilisation dans les délais et le temps total de la création à la comptabilisation. Source des données : 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 est-ce 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. Source des données : 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 de journal 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 est-ce 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. Source des données : 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
	Comptabilisation 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 est-ce 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. Source des données : 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
	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 est-ce 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. Source des données : 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 est-ce 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. Source des données : 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 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 est-ce important ? : Le suivi du reprises est indispensable 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 reprises. Source des données : 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 de l'é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
	Écriture de journal 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 est-ce important ? : Cette activité est indispensablele pour l'analyse des boucles de reprise, 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. Source des données : 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 de journal 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 est-ce 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 points de blocage cachés si l'étape de révision est informelle mais chronophage. Source des données : 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
	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 est-ce 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. Source des données : 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

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 > Template 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 impératif 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' dans 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 indispensable 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 Template 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élèvement.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 indispensable 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 > Template 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 impératif 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' dans 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 indispensable 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 pour la Comptabilité et Reporting - Écritures comptables

Votre modèle de données pour la Comptabilité et Reporting - Écritures comptables

Comptabilité et Reporting - Attributs des écritures comptables.

Comptabilité et Reporting - 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 Clôture et rapports financiers (Du Grand Livre au rapport) - Saisie des écritures comptables dès aujourd'hui

Votre modèle de données pour la Comptabilité et Reporting - Écritures comptables

Votre modèle de données pour la Comptabilité et Reporting - Écritures comptables

Comptabilité et Reporting - Attributs des écritures comptables.

Comptabilité et Reporting - 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 Clôture et rapports financiers (Du Grand Livre au rapport) - Saisie des écritures comptables dès aujourd'hui