> Amélioration continue des processus > Comptabilisation des écritures, de l’enregistrement au reporting > Oracle Fusion Financials > Modèle de données

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

Oracle Fusion Financials

← Retour au guide d’amélioration

Attributs du processus Record to Report - Écriture comptable(21) Activités du processus Record to Report - Écriture comptable(12) Guides d’extraction(4)

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

Ce modèle de données vous guide dans l’extraction et la structuration des données d’écritures comptables d’Oracle Fusion Financials. Il présente les attributs essentiels à recueillir et les principales activités à suivre afin de réunir les informations nécessaires à une analyse approfondie des processus. Vous y trouverez également des conseils pratiques pour extraire ces données directement de votre système.

Attributs recommandés à recueillir
Activités clés à suivre
Guide d’extraction pour Oracle Fusion Financials

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du processus Record to Report - Écriture comptable

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail le processus Record to Report - Écriture comptable.

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l’événement métier ou de la tâche qui s’est produit à un moment donné du processus de traitement de l’écriture comptable.
Description Le nom de l’activité décrit une étape du cycle de vie de l’écriture comptable, par exemple « Journal Entry Created » ou « Journal Entry Approved ». Ces données sont essentielles pour construire la carte du processus et comprendre la séquence des événements. L’analyse des activités permet de repérer le flux de processus, notamment les parcours habituels, les écarts et les boucles de reprise. Le suivi des différentes activités permet de mesurer le temps passé à chaque étape, comme l’approbation, et de repérer celles qui prennent le plus de temps ou sont les plus sujettes aux erreurs. Pourquoi est-ce important ? Cet attribut définit les étapes du processus. Il constitue la base de la carte du processus et permet d’analyser le flux, les goulots d’étranglement et les variations. Où trouver ces données Cet attribut est généralement établi à partir des changements de statut, des journaux d’événements ou des tables de piste d’audit associées aux objets d’écriture comptable du module Grand livre. Exemples Journal Entry CreatedJournal Submitted For ApprovalÉcriture comptable approuvéeÉcriture comptable comptabilisée
	Heure de début EventTime	Horodatage indiquant le moment où une activité ou un événement précis s’est produit.
Description Cet horodatage indique la date et l’heure exactes d’exécution d’une activité. Il s’agit du principal repère temporel utilisé en Process Mining pour déterminer l’ordre des événements et calculer les durées qui les séparent. La précision de l’heure de l’événement est essentielle pour toutes les analyses temporelles, notamment le calcul des temps de cycle, le repérage des goulots d’étranglement et le suivi des performances au regard des accords de niveau de service. Elle fournit l’ordre chronologique nécessaire pour reconstituer le déroulement réel du processus. Pourquoi est-ce important ? Cet horodatage est indispensable pour ordonner les événements, calculer les durées du processus et effectuer toute analyse temporelle. Où trouver ces données Ces informations sont généralement stockées dans des tables de piste d’audit ou dans un champ « Last Update Date » ou « Creation Date » des tables de transactions, comme GL_JE_HEADERS et GL_JE_LINES, pour les événements concernés. Exemples 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	Identifiant de l’écriture comptable JournalEntryId	Identifiant unique d’une écriture comptable, qui relie toutes les activités associées à la transaction financière.
Description L’identifiant de l’écriture comptable sert d’identifiant principal du cas et relie de manière unique toutes les activités associées à un ensemble précis de transactions financières. Il permet de suivre le cycle de vie complet d’une écriture, de son lancement à sa comptabilisation finale, et de vérifier que tous les débits et crédits sont pris en compte. En Process Mining, cet identifiant est indispensable pour reconstituer le parcours de chaque écriture comptable de bout en bout. Il relie des événements distincts, comme « Journal Entry Created », « Journal Submitted For Approval » et « Journal Entry Posted », au sein d’un flux de processus cohérent. Vous pouvez ainsi analyser les temps de cycle, les goulots d’étranglement et les variations du processus. Pourquoi est-ce important ? Il s’agit de la clé fondamentale pour suivre une écriture comptable de bout en bout et analyser l’ensemble du flux de processus de chaque cas. Où trouver ces données Cette clé primaire figure dans les tables principales du grand livre, comme GL_JE_HEADERS et GL_JE_LINES. Exemples JE100523JE202311001882019
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation ou extraction des données depuis le système source.
Description Cet attribut indique la date de la dernière mise à jour du jeu de données. Il renseigne sur l’actualité des données analysées, ce qui permet de mieux apprécier la pertinence des résultats obtenus. Dans toute analyse, notamment dans les Dashboards opérationnels, connaître l’heure de la dernière mise à jour des données est essentiel pour que les utilisateurs puissent se fier aux données et prendre des décisions éclairées. Cela indique clairement la date limite des données incluses dans le modèle de Process Mining. Pourquoi est-ce important ? Indique l’actualité des données, afin que les utilisateurs sachent si l’analyse du processus est à jour et puissent se fier aux résultats. Où trouver ces données Cette valeur est générée et enregistrée lors de l’extraction et de la transformation des données. Elle correspond généralement à l’horodatage de fin de la tâche ETL/ELT. Exemples 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Système source SourceSystem	Système ou module d’origine des données.
Description Cet attribut indique le système source dont proviennent les données du processus. Dans un environnement informatique complexe, les données peuvent être issues de plusieurs systèmes intégrés ; ce champ permet de les distinguer. Pour analyser un processus, connaître le système source est important afin de comprendre les variations qui peuvent découler du comportement de chaque système. Cette information facilite également la validation des données et le diagnostic des problèmes en permettant de remonter à leur origine. Pourquoi est-ce important ? Indique l’origine des données, une information importante pour leur gouvernance et leur validation, ainsi que pour comprendre les variations du processus entre les systèmes. Où trouver ces données Il s’agit souvent d’une valeur statique définie lors de l’extraction des données. Elle peut aussi provenir d’un champ des tables sources qui indique le système de saisie. Exemples Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Catégorie d’écriture comptable JournalCategory	Catégorie de l’écriture comptable, par exemple « Accrual », « Adjustment » ou « Reclassification ».
Description La catégorie d’écriture comptable classe les écritures selon leur finalité métier. Cette classification permet une analyse plus détaillée du processus, car les différentes catégories peuvent suivre des flux de processus, des règles d’approbation ou des temps de cycle distincts. Par exemple, les écritures d’ajustement de fin de mois peuvent suivre un processus plus complexe et plus urgent que les charges à payer courantes. L’analyse par catégorie permet de mettre au jour ces variations et d’adapter les améliorations aux différents types d’écritures. Pourquoi est-ce important ? Permet de segmenter le processus selon la finalité métier de l’écriture et de faire ressortir les différences de comportement et de performance entre les types d’écritures. Où trouver ces données Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé JE_CATEGORY. Exemples Charge à payerManuelleAjustementRéévaluation
	Montant de l’écriture comptable JournalAmount	Valeur monétaire totale de l’écriture comptable, généralement égale à la somme des débits.
Description Cet attribut représente la valeur financière totale de la transaction enregistrée dans l’écriture comptable. Le montant peut influer considérablement sur le processus. Par exemple, les écritures de montant élevé peuvent nécessiter des étapes d’approbation supplémentaires ou un examen plus approfondi. L’analyse du montant de l’écriture comptable permet de segmenter les cas selon leur incidence financière. Elle aide à répondre à des questions comme « Les écritures de montant élevé prennent-elles plus de temps à approuver ? » ou « Les écritures dépassant un certain seuil sont-elles plus souvent rejetées ? ». Ces informations apportent un contexte métier important au flux de processus. Pourquoi est-ce important ? Apporte un contexte métier important et permet d’analyser les écritures selon leur incidence financière, notamment pour déterminer si celles de montant élevé suivent un processus différent. Où trouver ces données Cette valeur correspond généralement à 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 du rejet RejectionReason	Description textuelle ou code indiquant pourquoi une écriture comptable a été rejetée.
Description Lorsqu’une écriture comptable est rejetée pendant le processus d’approbation, cet attribut enregistre le motif du rejet. Il peut s’agir d’un code prédéfini ou d’un commentaire libre de la personne chargée de l’approbation. Cet attribut compte parmi les plus importants pour analyser les causes profondes des inefficacités du processus. L’analyse des motifs de rejet les plus fréquents permet aux organisations de repérer les améliorations possibles : mieux former les personnes qui préparent les écritures, clarifier les consignes ou renforcer les contrôles du système. Cet attribut contribue directement au Dashboard « Journal Entry Rejection Rate Analysis ». Pourquoi est-ce important ? Met en évidence les causes profondes des reprises et des retards du processus, ce qui permet de cibler les améliorations pour réduire le taux de rejet. Où trouver ces données Ces informations peuvent être stockées dans les tables de flux de travail ou de piste d’audit associées au processus d’approbation, ou dans un champ de notes de l’en-tête de l’écriture. Exemples Combinaison de comptes incorrectePièces justificatives insuffisantesDépassement du budget
	Service de l’utilisateur UserDepartment	Service ou équipe auquel appartient l’utilisateur ayant effectué l’activité.
Description Cet attribut apporte un contexte organisationnel en associant une activité à un service précis, comme « Finance », « Accounting Operations » ou « Internal Audit ». Il est généralement établi à partir des données de référence des utilisateurs. L’analyse par service permet de repérer les goulots d’étranglement entre services, de comparer les performances des équipes et de comprendre les différences d’exécution du processus au sein de l’organisation. Elle aide à répartir les ressources et à cibler les initiatives d’amélioration des processus. Pourquoi est-ce important ? Apporte un contexte organisationnel qui permet d’analyser les performances par équipe ou par service et de repérer les inefficacités entre fonctions. Où trouver ces données Cette information ne figure généralement pas dans les tables de transactions. Il faut la récupérer en reliant UserName à une table de référence des utilisateurs ou aux données du système RH. Exemples Comptabilité généraleRapports financiersComptes fournisseurs
	Source de l’écriture comptable JournalSource	Sous-grand livre ou source à l’origine de l’écriture comptable, par exemple « Payables », « Receivables » ou « Manual ».
Description Cet attribut indique l’origine de l’écriture comptable dans le système ERP. Les écritures peuvent être créées manuellement dans le grand livre ou générées automatiquement à partir de sous-grands livres, comme ceux des comptes fournisseurs, des comptes clients ou des immobilisations. La source de l’écriture comptable est un attribut important pour analyser l’automatisation. Elle permet de distinguer les écritures manuelles de celles générées par le système et contribue au calcul du KPI « Automated Journal Entry Rate ». Les processus associés aux différentes sources varient souvent considérablement en complexité et en efficacité. Pourquoi est-ce important ? Distingue les écritures manuelles des écritures automatisées, ce qui est essentiel pour mesurer le taux d’automatisation et analyser les différences entre les processus. Où trouver ces données Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé JE_SOURCE. Exemples ManuelleComptes fournisseursImmobilisationsComptes clients
	Utilisateur UserName	Utilisateur ayant effectué l’activité, par exemple la création, l’approbation ou la comptabilisation de l’écriture.
Description Cet attribut identifie l’employé ou l’utilisateur système qui a exécuté une activité. Il est essentiel pour comprendre la répartition de la charge de travail et les performances, ainsi que pour repérer les goulots d’étranglement individuels. L’attribut UserName permet de filtrer les processus par utilisateur, de comparer leur efficacité et d’examiner les causes des retards ou des erreurs. Il alimente directement des Dashboards comme « User Workload & Efficiency Across Teams » et des KPI comme « User Journal Bottleneck Index ». Pourquoi est-ce important ? Cet attribut associe les étapes du processus aux personnes qui en sont responsables. Il permet d’analyser la charge de travail, les performances individuelles et les besoins en formation. Où trouver ces données Cet attribut figure dans des tables de transactions comme GL_JE_HEADERS (par exemple, CREATED_BY, LAST_UPDATED_BY) et dans les tables de piste d’audit associées. Exemples john.doesusan.smithautoprocess_user
	Comptabilisation dans les délais IsOnTimePosting	Indicateur calculé, vrai si l’écriture a été comptabilisée au plus tard à la date cible.
Description Cet attribut booléen est calculé en comparant l’horodatage de l’activité « Journal Entry Posted » à la date cible de comptabilisation. Si la comptabilisation a lieu à la date cible ou avant, la valeur est « true » ; sinon, elle est « false ». Cet attribut facilite directement le calcul du KPI « On-Time Journal Posting Rate ». Il permet de filtrer et d’analyser facilement les écritures en retard afin d’en repérer les causes fréquentes, comme certaines catégories d’écritures ou certaines personnes chargées de l’approbation. Pourquoi est-ce important ? Fournit un résultat binaire clair sur le respect des délais de comptabilisation, ce qui simplifie l’analyse des taux de ponctualité et des causes profondes des retards. Où trouver ces données Cet attribut est calculé par l’outil de Process Mining. Il nécessite l’attribut « TargetPostingDate » et l’horodatage de l’activité « Journal Entry Posted ». Exemples truefalse
	Date cible de comptabilisation TargetPostingDate	Date limite prévue pour la comptabilisation de l’écriture.
Description La date cible de comptabilisation correspond à la date limite à laquelle une écriture doit être comptabilisée dans le grand livre. Elle est souvent définie par des accords de niveau de service (SLA) ou par le calendrier de clôture de fin de mois et sert de référence pour mesurer les performances. Cet attribut est essentiel au calcul du KPI « On-Time Journal Posting Rate ». En comparant la date réelle de comptabilisation à la date cible, le système peut signaler automatiquement les écritures comptabilisées dans les délais ou en retard et mesurer clairement le respect du calendrier. Pourquoi est-ce important ? Définit l’accord de niveau de service ou la date limite de comptabilisation et permet de calculer les KPI de respect des délais. Où trouver ces données Il ne s’agit pas nécessairement d’un champ standard. Cette date peut être calculée à partir de règles métier fondées sur la date de création, la période comptable ou la catégorie de l’écriture. Exemples 2023-10-312023-11-302024-01-05
	Devise CurrencyCode	Code de devise associé au montant de l’écriture comptable, par exemple USD, EUR ou GBP.
Description Le code de devise indique la devise des montants financiers de l’écriture comptable. Il est indispensable aux organisations multinationales qui effectuent des transactions dans plusieurs devises. Cet attribut garantit une interprétation correcte des montants financiers. Il permet de filtrer les données par devise et est nécessaire pour toute analyse comparant ou agrégeant des montants entre différentes régions. Pourquoi est-ce important ? Fournit le contexte nécessaire à l’interprétation des montants financiers et permet de réaliser des analyses par devise. Où trouver ces données Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé CURRENCY_CODE. Exemples USDEURGBPJPY
	Heure de fin EndTime	Horodatage indiquant le moment où une activité précise a été achevée.
Description L’heure de fin marque l’achèvement d’une activité. L’heure de début en indique le commencement ; l’heure de fin permet d’en calculer précisément la durée de traitement. Cette information est essentielle pour calculer la durée de traitement des activités, une mesure clé pour repérer les goulots d’étranglement et évaluer l’efficacité des ressources. Par exemple, la différence entre l’heure de fin et l’heure de début de l’activité « Journal Entry Reviewed » indique le temps réellement consacré à cette tâche par la personne chargée de l’examen. Pourquoi est-ce important ? Elle permet de calculer la durée réelle ou la durée de traitement de chaque activité, ce qui est essentiel pour repérer les problèmes d’efficacité. Où trouver ces données Comme l’heure de début, cette information figure souvent dans les tables de piste d’audit. Elle peut aussi être déduite 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 de contrepassation ReversalIndicator	Indicateur précisant si l’écriture comptable contre-passe une autre écriture.
Description Cet attribut booléen identifie les écritures comptables créées pour contrepasser une écriture déjà comptabilisée. Les contrepassations constituent un type particulier d’écriture, qui suit souvent un processus distinct et parfois problématique. L’analyse de cet indicateur est essentielle pour alimenter le Dashboard « Journal Reversal Process Performance ». Elle permet d’isoler les processus de contrepassation afin d’en mesurer la fréquence, les causes et les temps de cycle, et de repérer les problèmes sous-jacents des écritures d’origine qui ont nécessité une contrepassation. Pourquoi est-ce important ? Permet d’isoler et d’analyser le processus de contrepassation, souvent révélateur d’erreurs ou de problèmes dans la transaction d’origine. Où trouver ces données Il peut s’agir d’un indicateur spécifique dans la table GL_JE_HEADERS, comme ACCRUAL_REV_FLAG, ou d’un lien vers l’écriture d’origine qui a été contrepassée. Exemples truefalse
	Nom du grand livre LedgerName	Nom du grand livre dans lequel l’écriture comptable est enregistrée.
Description Le nom du grand livre indique le grand livre auquel appartient l’écriture comptable. Les organisations qui comptent plusieurs entités juridiques ou doivent répondre à différentes exigences de reporting peuvent utiliser plusieurs grands livres, par exemple un grand livre principal pour la comptabilité du groupe et des grands livres secondaires pour les rapports réglementaires locaux. Cet attribut est essentiel pour filtrer et comparer les processus entre entités juridiques ou unités opérationnelles. Il garantit que les analyses sont réalisé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 les analyses de processus entre entités juridiques ou référentiels comptables, un besoin essentiel pour les grandes organisations. Où trouver ces données Disponible dans la table GL_JE_HEADERS, généralement via LEDGER_ID, qui peut être relié à GL_LEDGERS pour obtenir le nom du grand livre. Exemples Grand livre principal des États-UnisGrand livre réglementaire du Royaume-UniGrand livre de consolidation mondial
	Période comptable AccountingPeriod	Période comptable à laquelle l’écriture est comptabilisée, par exemple « Jan-24 ».
Description La période comptable indique la période financière au cours de laquelle la transaction est comptabilisée. Elle est fondamentale pour le reporting et l’analyse financière. En Process Mining, cet attribut est essentiel à l’analyse des tendances. Il permet de comparer les performances du processus, par exemple les temps de cycle ou les taux de rejet, entre différents mois ou trimestres. Vous pouvez ainsi repérer les effets saisonniers, comme l’augmentation de la charge de travail lors des clôtures de fin de mois, et mesurer l’incidence des améliorations au fil du temps. Pourquoi est-ce important ? Permet d’analyser l’évolution des KPI, de mesurer les améliorations du processus et de repérer les tendances saisonnières, comme la pression liée aux clôtures de fin de mois. Où trouver ces données Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé PERIOD_NAME. Exemples Janv.-24Févr.-24Mars-24
	Reprise effectuée IsRework	Indicateur calculé, vrai si l’écriture comptable a fait l’objet d’un cycle de rejet et de correction.
Description Cet attribut booléen est calculé pour repérer les cas ayant fait l’objet de reprises. Il prend généralement la valeur « true » pour toute activité qui suit un événement « Journal Entry Rejected », par exemple « Journal Corrected and Resubmitted ». L’indicateur de reprise facilite l’analyse en permettant de quantifier le volume et l’incidence des boucles de reprise. Il contribue directement au KPI « Average Journal Rework Rate » et permet de comparer le flux de processus et la durée des cas repris à ceux traités correctement dès la première fois. Pourquoi est-ce important ? Signale directement les cas ayant suivi des boucles de reprise inefficaces et permet d’en quantifier facilement la fréquence et l’incidence sur le processus. Où trouver ces données Cette information n’est pas disponible dans le système source. Elle est calculée dans l’outil de Process Mining à partir de la séquence des activités de chaque cas. Exemples truefalse
	Statut de comptabilisation PostingStatus	Statut actuel de comptabilisation de l’écriture, par exemple « Unposted » ou « Posted ».
Description Cet attribut indique l’état actuel de l’écriture comptable au regard de sa comptabilisation dans le grand livre. Il permet de savoir où en est l’écriture dans son cycle de vie, en particulier lorsqu’elle est encore en cours de traitement. Le statut de comptabilisation est essentiel au Dashboard « Real-Time Journal Entry Status Tracker », qui donne une vue d’ensemble des écritures en cours. Il permet de surveiller les écritures en attente de comptabilisation et de repérer les retards dans les dernières étapes du processus. Pourquoi est-ce important ? Indique l’état actuel d’une écriture, une information essentielle pour surveiller les retards et suivre les écritures en cours de traitement. Où trouver ces données Disponible dans la table GL_JE_HEADERS, généralement dans une colonne nommée STATUS ou POSTING_STATUS. Exemples ComptabiliséeNon comptabiliséeErreur
	Temps de cycle de bout en bout EndToEndCycleTime	Durée totale calculée entre la création de l’écriture comptable et son rapprochement final.
Description Cette métrique représente le temps total passé par une écriture comptable dans l’ensemble du processus, du premier événement « Journal Entry Created » à l’événement final « Journal Entry Reconciled ». Elle donne une vue d’ensemble des performances du processus. Il s’agit d’un KPI de référence pour mesurer l’efficacité globale du processus. Les Dashboards de tendances permettent de suivre l’incidence des initiatives d’amélioration au fil du temps et de disposer d’une valeur de référence pour évaluer les changements apportés au processus. Pourquoi est-ce important ? Fournit une mesure globale de l’état et de l’efficacité du processus, ce qui en fait une métrique importante pour le reporting destiné à la direction. Où trouver ces données La plateforme de Process Mining calcule cette métrique en mesurant l’écart entre les horodatages du premier et du dernier événement de chaque cas. Exemples P10DT5HP4DT12HP22D

Obligatoire Recommandé Facultatif

Activités du processus Record to Report - Écriture comptable

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir avec précision le processus de création des écritures comptables.

5 Recommandé 7 Facultatif

	Activité	Description
	Écriture comptable approuvée	La personne chargée de l’approbation a formellement approuvé l’écriture comptable, confirmant son exactitude et sa validité. Il s’agit de la dernière étape du flux de travail d’approbation, après laquelle l’écriture peut être comptabilisée.
Pourquoi est-ce important ? Cette étape marque la fin du processus d’approbation. Le délai entre la soumission et l’approbation est un KPI important pour mesurer l’efficacité du flux de travail et repérer les goulots d’étranglement dans les approbations. Où trouver ces données Cet événement est déduit d’un changement de statut dans la table GL_JE_HEADERS, lorsque APPROVAL_STATUS_CODE prend la valeur « APPROVED ». Les tables de flux de travail contiennent l’identité de la personne chargée de l’approbation et l’horodatage. Données à recueillir Suivez l’horodatage auquel APPROVAL_STATUS_CODE passe à « APPROVED » dans GL_JE_HEADERS. Type d’événement inferred
	Écriture comptable comptabilisée	Les données financières de l’écriture comptable ont été enregistrées dans le grand livre. Les débits et les crédits sont désormais pris en compte dans les soldes des comptes.
Pourquoi est-ce important ? Cette étape importante marque l’inscription de l’écriture dans les comptes officiels. Elle est essentielle pour mesurer le taux de comptabilisation dans les délais et le délai total entre la création et la comptabilisation. Où trouver ces données Cet événement est déduit d’un changement de statut dans la table GL_JE_HEADERS, lorsque le champ STATUS prend la valeur « P » (comptabilisé). La table GL_JE_BATCHES contient également un statut de comptabilisation. Données à recueillir Suivez l’horodatage auquel STATUS passe à « P » dans GL_JE_HEADERS. Type d’événement inferred
	Écriture comptable rapprochée	L’écriture comptable a été rapprochée et soldée lors du rapprochement des comptes de fin de période. Cela confirme que la transaction concorde avec d’autres données financières, comme les relevés bancaires.
Pourquoi est-ce important ? Cette activité constitue une véritable étape finale du cycle de vie de l’écriture. Le délai entre la comptabilisation et le rapprochement est un KPI important pour évaluer l’efficacité du processus de clôture financière. Où trouver ces données Cet événement est généralement enregistré 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 de l’enregistrement de rapprochement associé à l’écriture. Données à recueillir Mettez en correspondance les données de l’écriture avec les mises à jour du statut de rapprochement dans les tables ARCS ou FCCS. Type d’événement inferred
	Journal Entry Created	Cette activité marque le début du processus de saisie d’une écriture. Elle correspond au moment où un utilisateur crée un nouvel en-tête d’écriture et commence à saisir les données, avant toute soumission pour vérification ou approbation.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus. Mesurer le temps écoulé entre cette activité et les étapes suivantes permet d’évaluer l’efficacité de la saisie initiale et le temps de cycle global. Où trouver ces données Cet événement est généralement déduit de l’horodatage de création dans la table GL_JE_HEADERS pour un Journal Entry ID donné. Cette table contient également l’utilisateur qui a créé l’enregistrement. Données à recueillir Utilisez la colonne CREATION_DATE de la table GL_JE_HEADERS. Type d’événement inferred
	Journal Submitted For Approval	Cette activité a lieu lorsque l’utilisateur soumet officiellement l’écriture terminée au flux de travail d’approbation. L’écriture passe alors de l’état brouillon ou incomplet à l’état en attente d’approbation.
Pourquoi est-ce important ? Cette étape importante marque le début du calcul du temps de cycle d’approbation et permet de repérer les goulots d’étranglement. Elle sépare la phase de saisie des données de celle de vérification et d’approbation. Où trouver ces données Cet événement est déduit d’un changement de statut dans la table GL_JE_HEADERS, notamment lorsque la valeur de APPROVAL_STATUS_CODE devient « REQUIRED » ou « INITIATED ». L’horodatage de soumission peut également être enregistré. Données à recueillir Suivez l’horodatage auquel APPROVAL_STATUS_CODE dans GL_JE_HEADERS change pour indiquer la soumission. Type d’événement inferred
	Comptabilisation vérifiée	Après la comptabilisation, une personne ou un système vérifie que l’écriture a été comptabilisée correctement et que les soldes sont conformes aux attentes. Il s’agit souvent d’un contrôle manuel.
Pourquoi est-ce important ? L’analyse de cette activité permet de comprendre le temps consacré aux contrôles manuels et à l’assurance qualité après la comptabilisation. Elle peut aussi révéler des possibilités d’automatiser les vérifications. Où trouver ces données Il est peu probable que cet événement soit explicite dans Oracle Fusion. Il faudrait le déduire d’autres actions, par exemple l’exécution d’un rapport précis par un utilisateur ou la mise à jour d’un champ de statut personnalisé, qui ne fait pas partie de la configuration standard. Données à recueillir Une logique personnalisée est nécessaire, par exemple pour suivre l’heure d’exécution des rapports de vérification ou les mises à jour d’un champ flexible descriptif. Type d’événement inferred
	Contrepassation de l’écriture traitée	Une écriture de contrepassation a été créée et comptabilisée au cours d’une période ultérieure afin d’annuler l’incidence financière de l’écriture d’origine. Cette opération est courante pour les charges à payer.
Pourquoi est-ce important ? Le suivi des contrepassations permet de repérer les types d’écritures fréquemment contrepassées et d’analyser l’efficacité du processus de contrepassation. Cela peut révéler des problèmes de gestion des charges à payer. Où trouver ces données Cet événement est déduit en repérant une nouvelle écriture explicitement liée à l’écriture d’origine comme sa contrepassation. La table GL_JE_HEADERS contient des champs comme REVERSAL_PERIOD et REVERSAL_FLAG, qui permettent d’identifier et de relier ces écritures. Données à recueillir Repérez les dates de création et de comptabilisation de la nouvelle écriture dont l’en-tête indique que l’écriture d’origine a été contrepassée. Type d’événement inferred
	Journal Corrected and Resubmitted	Après le rejet d’une écriture, son créateur apporte les corrections nécessaires et la soumet de nouveau pour approbation. Cette activité marque le début d’un nouveau cycle d’approbation pour la même écriture.
Pourquoi est-ce important ? Le suivi des reprises est essentiel pour comprendre les inefficacités du processus. Associée à l’activité « Journal Entry Rejected », cette activité permet de mesurer la durée et la fréquence des reprises. Où trouver ces données Il s’agit d’un événement « Journal Submitted For Approval » ultérieur pour une écriture qui était auparavant à l’état « REJECTED ». Il est identifié en analysant la séquence des changements de statut associés à un même identifiant d’écriture. Données à recueillir Repérez l’horodatage d’une soumission qui survient après un rejet pour le même identifiant de cas. Type d’événement inferred
	Journal Entry Rejected	Un approbateur a vérifié l’écriture et l’a rejetée en raison d’erreurs, de pièces justificatives manquantes ou du non-respect des règles. L’écriture est alors renvoyée à son créateur pour correction.
Pourquoi est-ce important ? Cette activité est importante pour analyser les boucles de reprise, les taux de rejet et les indicateurs de réussite dès la première soumission. Des rejets fréquents signalent des problèmes de qualité des données ou de formation. Où trouver ces données Cet événement est déduit d’un changement de statut dans la table GL_JE_HEADERS, lorsque APPROVAL_STATUS_CODE prend la valeur « REJECTED ». L’historique du flux de travail consigne l’utilisateur et l’horodatage de cette action. Données à recueillir Suivez l’horodatage auquel APPROVAL_STATUS_CODE dans GL_JE_HEADERS prend la valeur « REJECTED ». Type d’événement inferred
	Journal Entry Reviewed	Cette étape de vérification peut avoir lieu avant l’approbation officielle ou en faire partie. Un collègue ou un responsable vérifie l’exactitude et la conformité de l’écriture avant son examen par l’approbateur final.
Pourquoi est-ce important ? Isoler cette activité permet de distinguer le temps consacré à la vérification préliminaire de celui de l’approbation finale. Cela peut révéler des goulots d’étranglement difficiles à repérer lorsque la vérification est informelle, mais longue. Où trouver ces données Cette étape peut être explicitement prévue dans un flux de travail d’approbation à plusieurs niveaux et enregistrée dans les tables d’historique du flux de travail. Si elle est informelle, elle n’est pas consignée. Elle peut être déduite lorsqu’une action d’un utilisateur précis est enregistrée avant la décision d’approbation finale. Données à recueillir Analysez les tables d’historique du flux de travail pour repérer les étapes intermédiaires d’approbation ou de vérification avant le statut final « Approved ». Type d’événement inferred
	Lancement de la comptabilisation de l’écriture	Le processus de comptabilisation de l’écriture approuvée dans le grand livre a commencé. Cette étape peut être automatisée ou manuelle ; elle place l’écriture dans la file d’attente du programme de comptabilisation.
Pourquoi est-ce important ? Cette activité distingue l’approbation du processus technique de comptabilisation. Un délai entre l’approbation et le lancement de la comptabilisation peut signaler des problèmes de planification ou un manque de ressources dans le moteur de comptabilisation. Où trouver ces données Cet événement peut être déduit des changements de statut dans la table GL_JE_BATCHES ou de l’heure de soumission de la requête concurrente de comptabilisation associée au lot d’écritures. Données à recueillir Repérez l’heure de soumission de la requête du programme de comptabilisation du grand livre pour le lot d’écritures concerné. Type d’événement inferred
	Supporting Documentation Attached	Cette activité correspond à l’ajout de pièces justificatives, comme des factures ou des feuilles de calcul, à l’écriture comptable. Ces documents apportent souvent des éléments de contexte et des preuves aux auditeurs et aux approbateurs.
Pourquoi est-ce important ? Le suivi de cette activité aide à déterminer si des pièces manquantes sont à l’origine de retards. Il renseigne également sur la conformité et l’exhaustivité des écritures avant leur entrée dans le flux de travail d’approbation. Où trouver ces données Il peut être difficile de suivre cette activité comme un événement distinct. Elle peut être déduite des horodatages de tables de pièces jointes telles que FND_ATTACHED_DOCUMENTS, liées à l’enregistrement de l’écriture dans GL_JE_HEADERS. Données à recueillir Déduisez cette activité de la date de création des enregistrements de FND_ATTACHED_DOCUMENTS liés à l’écriture. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données d’Oracle Fusion Financials

Étapes

Accédez à l’espace de travail Rapports et analyses : Connectez-vous à Oracle Fusion Financials. Dans le menu Navigator, sélectionnez Tools, puis Reports and Analytics. Cet espace central permet de créer et de gérer toutes les analyses et tous les rapports.
Créez un modèle de données BI Publisher : Pour extraire ce type de journal d’événements, il est préférable de créer directement un modèle de données BI Publisher plutôt que de commencer par une analyse OTBI. Vous pourrez ainsi utiliser une requête SQL personnalisée avec des instructions UNION ALL. Cliquez sur le bouton « Browse Catalog », accédez à un dossier approprié, puis sélectionnez Create > Data Model.
Définissez le jeu 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 jeu de données, puis sélectionnez « SQL Query ». Donnez-lui un nom explicite, par exemple « JournalEventLog ».
Saisissez la requête SQL : Sélectionnez « Oracle BI EE » comme source de données. Copiez le script SQL complet de la section Query ci-dessous et collez-le dans la zone de texte SQL Query. La requête rassemble toutes les activités et tous les attributs requis dans une structure unifiée.
Définissez 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étecte automatiquement. Configurez-les comme paramètres, en choisissant les types appropriés (Date ou Text) et, si nécessaire, des valeurs par défaut. Vous pourrez ainsi exécuter le rapport avec différents critères.
Créez un rapport à partir du modèle de données : Après avoir enregistré le modèle de données, retournez au catalogue. Cliquez sur Create > Report. Dans l’assistant de création, sélectionnez « Use Existing Data Model », puis choisissez le modèle que vous venez de créer.
Configurez la mise en page du rapport : Dans l’éditeur de mise en page, choisissez le format « Table ». Faites glisser toutes les colonnes du modèle de données dans le tableau afin qu’elles figurent dans l’export. Aucune mise en forme complexe n’est nécessaire.
Définissez CSV comme format de sortie par défaut : Dans l’éditeur de rapport, cliquez sur le lien « View a List ». Dans la section « Output Formats », vérifiez que « CSV » est sélectionné. Il est conseillé de désélectionner les autres formats pour simplifier la planification. Enregistrez le rapport.
Planifiez l’extraction automatique du rapport : Recherchez le rapport enregistré dans le catalogue, cliquez sur « More », puis sur « Schedule ». Créez une nouvelle tâche planifiée et définissez sa fréquence, par exemple quotidienne ou hebdomadaire.
Configurez l’export et la livraison : Dans l’onglet « Output » de la tâche planifiée, indiquez les détails de sortie. Sélectionnez votre rapport et choisissez « CSV » comme format. Dans l’onglet « Destination », vous pouvez configurer la livraison du fichier vers un emplacement du serveur de contenu (UCM) ou un serveur SFTP externe pour automatiser sa récupération.
Récupérez et préparez les données : Une fois la tâche planifiée exécutée, récupérez le fichier CSV généré à l’emplacement configuré. Vérifiez que les en-têtes de colonnes correspondent aux exigences d’importation de ProcessMind : JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. Le fichier est alors prêt à être importé.

Configuration

Source de données : Exécutez la requête 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 utilisées par OTBI.
Domaines fonctionnels clés (à titre indicatif) : La logique de la requête s’appuie principalement sur le domaine « General Ledger - Journals Real Time ». Elle joint également des données provenant du domaine « HCM - Workforce Management - Worker Assignment Real Time » pour les informations sur les utilisateurs et, éventuellement, des domaines liés aux flux de travail pour l’historique des approbations.
Filtrage par période : Il est essentiel de limiter l’extraction à une période raisonnable. La requête comprend les paramètres :start_date et :end_date. Pour une première analyse, nous recommandons d’extraire trois à six mois de données. Le filtre porte sur 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 précis. L’extraction simultanée de tous les grands livres peut générer des fichiers très volumineux et entraîner des problèmes de performance.
Prérequis : La personne qui crée et planifie le rapport doit disposer des rôles BI appropriés, par exemple « BI Administrator » ou « BI Author ». Son profil de sécurité des données doit également autoriser l’accès aux grands livres et aux unités opérationnelles concernés.
Planification : Pour préserver les performances et éviter de perturber les utilisateurs du système, planifiez l’extraction en dehors des heures de pointe, par exemple pendant la nuit.

Exemple de requête sql

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édez à BI Publisher : Connectez-vous à Oracle Fusion Financials. Dans le menu Navigator, sélectionnez Tools, puis Reports and Analytics. Le catalogue Business Intelligence s’ouvre.
Créez un modèle de données : Dans le catalogue BI, cliquez sur Create, puis sélectionnez Data Model. L’éditeur de modèle de données s’ouvre.
Définissez le jeu de données de la requête SQL : Dans l’éditeur de modèle de données, cliquez sur l’icône plus de l’onglet Diagram, puis sélectionnez SQL Query. Dans la nouvelle fenêtre, nommez le jeu de données, par exemple ProcessMind_JE_EventLog. Sélectionnez la source de données appropriée, généralement FUSIONDB. Collez la requête SQL complète dans la zone de texte SQL Query.
Définissez les paramètres : La requête utilise les paramètres de période p_start_date et p_end_date. Oracle BI Publisher les détecte automatiquement. Configurez-les comme paramètres de type Text et attribuez-leur des libellés explicites, tels que « Start Date (YYYY-MM-DD) » et « End Date (YYYY-MM-DD) ».
Enregistrez 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 dans un dossier approprié, par exemple Shared Folders/Custom/ProcessMining.
Créez le rapport : Cliquez sur le bouton Create Report dans le coin supérieur droit de l’éditeur de modèle de données. L’assistant de création de rapport s’ouvre.
Configurez la mise en page du rapport : Dans l’assistant, choisissez d’utiliser le modèle de données actuel, puis sélectionnez le format « Table ». Faites glisser toutes les colonnes de la source de données dans la zone de mise en page du tableau. Désélectionnez l’option « Show Grand Totals Row ».
Enregistrez le rapport : Enregistrez-le dans le même dossier que le modèle de données. Choisissez un nom explicite, par exemple « Journal Entry Event Log Report ».
Définissez le format de sortie par défaut : Modifiez le rapport et accédez à l’onglet « Viewing ». Dans la section « Output Formats », vérifiez que CSV est sélectionné et, de préférence, définissez-le comme format par défaut. Le fichier obtenu pourra ainsi être utilisé directement.
Exécutez le rapport et exportez les données : Ouvrez le rapport et saisissez les dates de début et de fin demandées. Indiquez la période souhaitée, puis cliquez sur Apply. Une fois le rapport exécuté, cliquez sur Export et choisissez le format CSV pour télécharger le journal d’événements.
Préparez l’importation : Ouvrez le fichier CSV téléchargé. Vérifiez que les en-têtes de colonnes correspondent aux noms d’attributs attendus (JournalEntryId, ActivityName, EventTime, etc.) et que les données sont correctement formatées avant de les importer dans ProcessMind.

Configuration

Prérequis : La personne qui exécute le rapport doit disposer d’un rôle lui accordant les privilèges de sécurité nécessaires pour accéder aux données du grand livre, par exemple General Accountant 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 utiliser la connexion à la base de données de l’application FUSIONDB.
Paramètres de période : La requête utilise les paramètres p_start_date et p_end_date pour définir la période d’extraction. Pour préserver les performances, il est recommandé de commencer par trois à six mois de données.
Filtres du rapport : Dans les grandes organisations, il est vivement recommandé d’ajouter des filtres directement dans la clause WHERE de l’expression de table commune JournalHeaders de la requête. Le filtrage par LEDGER_ID ou LEGAL_ENTITY_ID est essentiel pour maîtriser le volume de données.
Performances : L’exécution de cette requête sur une grande base de données de production peut mobiliser des ressources importantes. Planifiez le rapport en dehors des heures de pointe afin de limiter son impact sur les performances du système.
Format de sortie : Le rapport doit produire un fichier CSV. Ce format structuré convient à l’importation dans les outils de Process Mining.

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 : Vérifiez que Python 3 est installé, ainsi que les bibliothèques requests et pandas. Vous aurez besoin d’un compte Oracle Fusion Financials disposant des autorisations nécessaires pour accéder à l’API REST General Ledger Journals. Munissez-vous de l’URL de votre instance Oracle Fusion, de votre nom d’utilisateur et de votre mot de passe.
Préparez le script : Créez un fichier de script Python. Commencez par importer les bibliothèques nécessaires : requests, json, pandas et datetime.
Configurez le script : Définissez les variables correspondant à vos identifiants Oracle Fusion et à l’URL de base. Indiquez également les paramètres d’extraction, notamment les dates de début et de fin de la requête.
Authentification : Le script utilise l’authentification de base. La bibliothèque requests encode le nom d’utilisateur et le mot de passe dans les en-têtes de la requête.
Définissez la fonction d’appel de l’API : Créez une fonction qui gère les requêtes API. Elle doit prendre en charge la pagination à l’aide des paramètres offset et limit. La fonction effectue des appels successifs jusqu’à la récupération de toutes les écritures comptables de la période indiquée.
Construisez la requête API : Utilisez le paramètre q de la requête API pour filtrer les écritures selon LastUpdateDate. Vous pourrez ainsi extraire les données d’une période précise, par exemple LastUpdateDate between '2023-01-01' and '2023-03-31'.
Lancez la récupération des données : Appelez la fonction pour récupérer les données depuis le point de terminaison .../fscmRestApi/resources/11.13.18.05/journals. Elle renverra la liste complète des écritures comptables.
Traitez et transformez les données : Parcourez chaque écriture renvoyée par l’API. Pour chacune, créez plusieurs lignes d’événement 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.
Structurez le journal d’événements : Enregistrez chaque ligne d’événement générée sous forme de dictionnaire dans une liste. Cette liste constituera les données brutes de votre journal d’événements.
Créez un DataFrame : Une fois toutes les écritures traitées, convertissez la liste de dictionnaires d’événements en DataFrame Pandas pour faciliter leur manipulation.
Finalisez les colonnes : Sélectionnez et renommez les colonnes du DataFrame pour qu’elles correspondent au schéma requis par ProcessMind : JournalEntryId, ActivityName, EventTime, UserName, etc.
Exportez au format CSV : Enregistrez le DataFrame final dans un fichier CSV. Vous pourrez ensuite importer directement ce fichier dans ProcessMind pour l’analyser.

Configuration

Identifiants : Un nom d’utilisateur et un mot de passe Oracle Fusion valides sont nécessaires 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 de terminaison de l’API, par exemple https://[your-instance].fa.us2.oraclecloud.com.
Point de terminaison de l’API : Le script utilise le point de terminaison fscmRestApi/resources/11.13.18.05/journals pour récupérer les données du grand livre.
Filtre de période : Configurez le script avec une start_date et une end_date pour limiter la période d’extraction. Pour une première analyse, une période de trois à six mois est recommandée. Pour une utilisation régulière, configurez des chargements incrémentiels quotidiens ou hebdomadaires.
Limite de pagination : Le paramètre limit détermine le nombre d’enregistrements récupérés par appel API. Une valeur comprise entre 200 et 500 offre généralement un bon équilibre entre le nombre d’appels et la taille de chaque réponse.
Rôles Oracle requis : Le compte utilisateur doit disposer des privilèges nécessaires pour lire les données des écritures comptables via l’API REST, par exemple le rôle General Accountant ou un rôle personnalisé offrant des autorisations équivalentes.

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

Vérifiez que BI Cloud Connector, les domaines General Ledger ou les Public View Objects requis d’Oracle Fusion Financials, ainsi que les autorisations nécessaires dans le système source sont disponibles dans votre environnement. Avec votre administrateur Oracle, confirmez la cible de livraison BICC configurée et les identifiants permettant d’y accéder.
Dans la console BI Cloud Connector, repérez les Public View Objects contenant les en-têtes et les lignes des écritures comptables, l’historique des approbations, les pièces jointes, le statut de comptabilisation, le statut de rapprochement et les informations d’extourne. Notez les noms exacts des objets et des attributs configurés dans votre environnement. Remplacez les espaces réservés du script d’extraction par ces noms avant de l’exécuter.
Configurez une tâche BICC pour les Public View Objects General Ledger sélectionnés. Utilisez une extraction incrémentielle lorsqu’un attribut de dernière mise à jour fiable est disponible. Pour le chargement initial, choisissez une période maîtrisée de trois à six mois, ou une autre période comptable approuvée.
Configurez BICC pour livrer les fichiers extraits à l’emplacement de stockage cloud prévu. Vérifiez le format des fichiers, le séparateur, l’encodage des caractères, la compression, le partitionnement, la convention de nommage et la fréquence de livraison. Conservez le point de reprise de l’extraction ou l’horodatage de la dernière extraction réussie.
Récupérez les fichiers livrés dans la zone de préparation approuvée. Chargez chaque fichier source dans la table ou la vue de préparation correspondante. Utilisez les associations exactes entre objets et attributs sources documentées pour votre environnement. Ne supposez pas qu’un Public View Object a la même structure que la table de base de données sous-jacente.
Normalisez les horodatages dans un même fuseau horaire et convertissez ceux des sources vers un type de données cohérent. Conservez l’horodatage de mise à jour source dans LastDataUpdate. Convertissez les identifiants et les attributs d’activité sources vers les noms de sortie utilisés par ProcessMind.
Exécutez la requête ci-dessous après avoir remplacé chaque espace réservé par le nom réel de l’objet et de l’attribut de préparation. La requête crée explicitement une ligne du journal d’événements pour chacune des 12 activités requises. Elle ne déduit pas les activités absentes des données sources.
Vérifiez que JournalEntryId, ActivityName, EventTime, SourceSystem et LastDataUpdate sont renseignés pour chaque ligne de sortie. Examinez les événements en double, l’ordre des horodatages, les écritures rejetées puis soumises à nouveau, les liens entre extournes et les enregistrements dont certains attributs facultatifs sont manquants.
Exportez le résultat dans un fichier délimité ou dans un autre format pris en charge par ProcessMind. Incluez les noms de colonnes exacts JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount et RejectionReason. Importez le fichier en configurant JournalEntryId comme identifiant de cas, ActivityName comme activité et EventTime comme horodatage de l’événement.

Configuration

Configurez BICC avec les Public View Objects General Ledger nécessaires pour les en-têtes et les lignes des écritures comptables, l’historique des approbations ou des flux de travail, les pièces jointes, les données de comptabilisation, de rapprochement et d’extourne. Vérifiez les noms exacts des objets et des attributs dans le catalogue BICC de votre environnement.
Pour l’extraction initiale, choisissez une période de trois à six mois. Ne l’étendez qu’après avoir vérifié le volume, la capacité de stockage, la durée d’extraction et le temps de traitement en aval.
Appliquez les filtres approuvés sur la date comptable ou la date de dernière mise à jour, le grand livre, l’entité juridique, l’unité opérationnelle, le code société s’il est disponible, la catégorie d’écriture, la source de l’écriture, le type de document s’il est disponible et le statut de l’écriture. Utilisez uniquement les filtres pris en charge par les Public View Objects sélectionnés.
Configurez l’extraction incrémentielle à l’aide de l’attribut de dernière mise à jour de la source et d’un point de reprise conservé. Si nécessaire, prévoyez une courte période de chevauchement pour tenir compte des mises à jour tardives, puis dédupliquez les données selon JournalEntryId, ActivityName, EventTime et l’identifiant d’événement source pertinent.
Vérifiez que tous les objets sources utilisent des clés d’extraction et des calendriers d’actualisation compatibles. Les données d’approbation, de pièces jointes, de comptabilisation, de rapprochement et d’extourne peuvent être actualisées à des moments différents.
Pour les grands volumes de données, partitionnez l’extraction par période comptable, grand livre, entité juridique ou autre attribut de partitionnement pris en charge par BICC. Évitez les extractions historiques sans restriction pendant les heures ouvrées.
Conservez les horodatages sources et ceux des mises à jour sources avant toute transformation. Documentez le fuseau horaire utilisé pour EventTime et LastDataUpdate.
Les prérequis comprennent l’accès à la console BI Cloud Connector, l’autorisation de configurer et d’exécuter les extractions sélectionnées, l’accès à la cible de stockage cloud configurée et à l’environnement de préparation, ainsi que l’autorisation de consulter les données General Ledger et les données de flux de travail requises.
Vérifiez que les modules Oracle Fusion Financials, la configuration des flux de travail, le stockage des pièces jointes, les processus de comptabilisation et les sources de données de rapprochement nécessaires sont activés pour les activités concernées.
Ne considérez pas l’absence d’un enregistrement source comme la preuve qu’une activité n’a pas eu lieu. Les données BICC dépendent des Public View Objects sélectionnés, des filtres, de la fréquence d’actualisation, de la durée de conservation et de l’historique disponible.

Exemple de requête sql

WITH
journal_created AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Created' AS ActivityName,
        CAST([Journal Created Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Created By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Created By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal header staging object]
    WHERE [Journal Created Timestamp attribute] IS NOT NULL
),
supporting_documentation_attached AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Supporting Documentation Attached' AS ActivityName,
        CAST([Attachment Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Attachment User attribute] AS VARCHAR(255)) AS UserName,
        CAST([Attachment User Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal attachment staging object]
    WHERE [Attachment Timestamp attribute] IS NOT NULL
),
journal_submitted_for_approval AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Submitted For Approval' AS ActivityName,
        CAST([Submission Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Submitter attribute] AS VARCHAR(255)) AS UserName,
        CAST([Submitter Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal approval staging object]
    WHERE [Submission Timestamp attribute] IS NOT NULL
),
journal_entry_reviewed AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Reviewed' AS ActivityName,
        CAST([Review Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Reviewer attribute] AS VARCHAR(255)) AS UserName,
        CAST([Reviewer Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal review staging object]
    WHERE [Review Timestamp attribute] IS NOT NULL
),
journal_entry_rejected AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Rejected' AS ActivityName,
        CAST([Rejection Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Rejector attribute] AS VARCHAR(255)) AS UserName,
        CAST([Rejector Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST([Rejection Reason attribute] AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal rejection staging object]
    WHERE [Rejection Timestamp attribute] IS NOT NULL
),
journal_corrected_and_resubmitted AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Corrected and Resubmitted' AS ActivityName,
        CAST([Correction Resubmission Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Resubmitter attribute] AS VARCHAR(255)) AS UserName,
        CAST([Resubmitter Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST([Rejection Reason attribute] AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal resubmission staging object]
    WHERE [Correction Resubmission Timestamp attribute] IS NOT NULL
),
journal_entry_approved AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Approved' AS ActivityName,
        CAST([Approval Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Approver attribute] AS VARCHAR(255)) AS UserName,
        CAST([Approver Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal approval staging object]
    WHERE [Approval Timestamp attribute] IS NOT NULL
),
journal_posting_initiated AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Posting Initiated' AS ActivityName,
        CAST([Posting Initiated Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Posting Initiated By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Posting Initiated By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal posting staging object]
    WHERE [Posting Initiated Timestamp attribute] IS NOT NULL
),
journal_entry_posted AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Posted' AS ActivityName,
        CAST([Posted Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Posted By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Posted By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal posting staging object]
    WHERE [Posted Timestamp attribute] IS NOT NULL
),
posting_verified AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Posting Verified' AS ActivityName,
        CAST([Posting Verification Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Verifier attribute] AS VARCHAR(255)) AS UserName,
        CAST([Verifier Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Posting verification staging object]
    WHERE [Posting Verification Timestamp attribute] IS NOT NULL
),
journal_entry_reconciled AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Reconciled' AS ActivityName,
        CAST([Reconciliation Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Reconciled By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Reconciled By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal reconciliation staging object]
    WHERE [Reconciliation Timestamp attribute] IS NOT NULL
),
journal_reversal_processed AS (
    SELECT
        CAST([Original Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Reversal Processed' AS ActivityName,
        CAST([Reversal Posted Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Reversal User attribute] AS VARCHAR(255)) AS UserName,
        CAST([Reversal User Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Reversal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal reversal staging object]
    WHERE [Reversal Posted Timestamp attribute] IS NOT NULL
)
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_created
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM supporting_documentation_attached
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_submitted_for_approval
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_reviewed
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_rejected
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_corrected_and_resubmitted
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_approved
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_posting_initiated
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_posted
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM posting_verified
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_reconciled
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_reversal_processed
ORDER BY JournalEntryId, EventTime, ActivityName;

Prêt à commencer ?

Utilisez ce modèle pour transformer les données de vos écritures comptables Oracle Fusion en analyses concrètes et raccourcir votre cycle Record to Report. Commencez dès aujourd’hui à optimiser vos opérations financières.

Retour au guide d’amélioration

Télécharger le modèle

Accélérez dès aujourd’hui le processus Record to Report - Écriture comptable

Réduisez de 30 % le temps de cycle des écritures comptables et optimisez vos opérations financières.

Démarrez l’essai gratuit

Aucune carte bancaire n’est requise. Activez votre essai dès maintenant.

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

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

Attributs du processus Record to Report - Écriture comptable

Activités du processus Record to Report - Écriture comptable

Guides d’extraction

Export de rapports Oracle OTBI et BI Publisher

Étapes

Configuration

Exemple de requête sql

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

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST d’Oracle Fusion Financials

Étapes

Configuration

Exemple de requête python

Extraction de données en masse avec BI Cloud Connector (BICC)

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Accélérez dès aujourd’hui le processus Record to Report - Écriture comptable

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

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

Attributs du processus Record to Report - Écriture comptable

Activités du processus Record to Report - Écriture comptable

Guides d’extraction

Export de rapports Oracle OTBI et BI Publisher

Étapes

Configuration

Exemple de requête sql

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

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST d’Oracle Fusion Financials

Étapes

Configuration

Exemple de requête python

Extraction de données en masse avec BI Cloud Connector (BICC)

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Accélérez dès aujourd’hui le processus Record to Report - Écriture comptable

Prêt à commencer ?