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

Votre template de données Record to Report - Journal Entry

Oracle Fusion Financials

← Retour au guide d’amélioration

Record to Report - Attributs des écritures comptables (21) Record to Report - Activités liées aux écritures comptables (12) Guides d’extraction (4)

Votre template de données Record to Report - Journal Entry

Ce template de données fournit un guide complet pour extraire et structurer les données de Journal Entry d’Oracle Fusion Financials. Il présente les attributs essentiels à collecter ainsi que les principales activités à suivre, afin de réunir toutes les informations nécessaires à une analyse fiable du processus. Vous y trouverez également des recommandations pratiques pour extraire directement ces données de votre système.

Attributs recommandés à collecter
Principales activités à suivre
Guide d’extraction pour Oracle Fusion Financials

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Record to Report - Attributs des écritures comptables

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

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Le nom de l’événement métier ou de la tâche précise qui s’est produite à un moment donné du processus de saisie d’écritures comptables.
Description Activity Name décrit une étape unique du cycle de vie d’une écriture comptable, telle que « Écriture comptable créée » ou « Écriture comptable approuvée ». Ces données sont essentielles pour créer la carte du processus et comprendre la séquence des événements. L’analyse des activités permet d’identifier le flux du processus, notamment les parcours standard, les écarts et les boucles de reprise. Le suivi des différentes activités permet de mesurer le temps consacré à certaines étapes, comme l’approbation, et d’identifier celles qui prennent le plus de temps ou génèrent le plus d’erreurs. Pourquoi c’est important Il définit les étapes du processus, constitue l’ossature de la carte du processus et permet d’analyser le flux, les goulots d’étranglement et les variations. Où les obtenir Cet attribut est généralement dérivé des changements de statut, des journaux d’événements ou des tables de piste d’audit associés aux objets d’écriture comptable du module General Ledger. Exemples Écriture comptable crééeÉcriture comptable soumise pour approbationÉcriture comptable approuvéeÉcriture comptable comptabilisée
	Heure de début EventTime	L’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 auxquelles une activité a été exécutée. Il constitue l’élément temporel principal utilisé en Process Mining pour déterminer la séquence des événements et calculer les durées qui les séparent. La précision de l’Event Time est essentielle pour toutes les analyses temporelles, notamment le calcul des durées de cycle, l’identification des goulots d’étranglement et le suivi de la performance par rapport aux accords de niveau de service. Elle fournit l’ordre chronologique nécessaire pour reconstituer le flux réel du processus. Pourquoi c’est important Cet horodatage est indispensable pour ordonner les événements, calculer toutes les durées du processus et réaliser toute analyse fondée sur le temps. Où les obtenir Ces informations sont généralement stockées dans les tables de piste d’audit ou sous la forme d’une « Last Update Date » ou d’une « Creation Date » dans des tables de transactions telles que 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	L’identifiant unique d’une écriture comptable, qui relie toutes les activités financières associées.
Description Le Journal Entry ID sert d’identifiant de cas principal 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 comptable, de son lancement à sa comptabilisation finale, en veillant à ce que tous les débits et crédits soient pris en compte. Dans le Process Mining, cet identifiant est indispensable pour reconstituer le parcours de bout en bout de chaque écriture comptable. Il relie des événements distincts tels que « Écriture comptable créée », « Écriture comptable soumise pour approbation » et « Écriture comptable comptabilisée » au sein d’un flux de processus cohérent, ce qui permet d’analyser les durées de cycle, les goulots d’étranglement et les variations du processus. Pourquoi c’est important Il s’agit de la clé fondamentale pour suivre une écriture comptable du début à la fin et analyser l’intégralité du flux de processus pour chaque cas unique. Où les obtenir Il s’agit d’une clé primaire présente dans les tables centrales du General Ledger, telles que GL_JE_HEADERS et GL_JE_LINES. Exemples JE100523JE202311001882019
	Dernière mise à jour des données LastDataUpdate	L’horodatage de l’actualisation ou de l’extraction la plus récente 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 fournit un contexte sur l’actualité des données analysées, ce qui est important pour évaluer la pertinence des analyses obtenues. 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 instaurer la confiance 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 c’est important Indique l’actualité des données afin que les utilisateurs comprennent jusqu’à quelle date porte l’analyse du processus et puissent se fier aux analyses obtenues. Où les obtenir Cette valeur est générée et enregistrée lors de l’extraction et de la transformation des données. Il s’agit généralement de l’horodatage auquel la tâche ETL/ELT s’est terminée. Exemples 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Système source SourceSystem	Le système ou le module à l’origine des données.
Description Cet attribut identifie le système source depuis lequel les données du processus ont été extraites. Dans un environnement informatique complexe, les données peuvent provenir de plusieurs systèmes intégrés, et ce champ permet de les différencier. Dans l’analyse des processus, connaître le système source est essentiel pour comprendre les variations qui peuvent être liées au comportement de différents systèmes. Cela facilite également la validation des données et le dépannage en permettant de remonter jusqu’à leur origine. Pourquoi c’est important Identifie l’origine des données, ce qui est essentiel pour la gouvernance et la validation des données, ainsi que pour comprendre les variations du processus entre les différents systèmes. Où les obtenir Il s’agit souvent d’une valeur statique configurée lors de l’extraction des données, ou d’un champ des tables sources identifiant le système de saisie. Exemples Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Catégorie d’écriture comptable JournalCategory	La catégorie de l’écriture comptable, telle que « Accrual », « Adjustment » ou « Reclassification ».
Description Journal Category classe les écritures selon leur finalité métier. Cette classification permet une analyse plus fine du processus, car les différentes catégories peuvent suivre des flux, des règles d’approbation ou des durées 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 du processus par catégorie permet de mettre ces variations en évidence et d’adapter les améliorations aux différents types d’écritures comptables. Pourquoi c’est important Permet de segmenter le processus selon la finalité métier de l’écriture et de révéler les comportements et les performances propres aux différents types d’écritures. Où les obtenir Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé JE_CATEGORY. Exemples ProvisionManuelAjustementRéévaluation
	Montant de l’écriture 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 enregistrée dans l’écriture comptable. Le montant peut fortement influencer le processus. Par exemple, les écritures d’un montant élevé peuvent nécessiter des étapes d’approbation supplémentaires ou des contrôles plus approfondis. L’analyse du montant de l’écriture permet de segmenter les cas selon leur impact financier. Elle aide à répondre à des questions telles que : « Les écritures d’un montant élevé prennent-elles plus de temps à approuver ? » ou « Les rejets sont-ils plus fréquents au-delà d’un certain seuil ? » Elle apporte ainsi un contexte métier important à l’analyse du processus. Pourquoi c’est important Apporte un contexte métier essentiel, permet d’analyser les cas selon leur impact financier et aide à déterminer si les écritures d’un montant élevé suivent un processus différent. Où les obtenir Cette valeur correspond généralement à la somme des débits ou des crédits de la table GL_JE_LINES pour une écriture donnée. Exemples 5000.00125000.75750.50
	Motif du rejet RejectionReason	Description textuelle ou code expliquant pourquoi une écriture comptable a été rejetée.
Description Lorsqu’une écriture comptable est rejetée pendant le processus d’approbation, cet attribut enregistre le motif du rejet. Il peut s’agir d’un code prédéfini ou d’un commentaire en texte libre saisi par l’approbateur. Il s’agit de l’un des attributs les plus importants pour analyser les causes profondes des inefficacités du processus. En étudiant les motifs de rejet les plus fréquents, les organisations peuvent identifier les axes d’amélioration, comme une meilleure formation des préparateurs, des consignes plus claires ou le renforcement des contrôles du système. Cet attribut contribue directement au Dashboard « Analyse du taux de rejet des écritures comptables ». Pourquoi c’est important Donne une visibilité directe sur les causes profondes des reprises et des retards du processus, afin de cibler les améliorations et de réduire le taux de rejet. Où les obtenir Ces informations peuvent être stockées dans les tables du flux de travail ou de la piste d’audit associées au processus d’approbation, ou dans un champ de notes de l’en-tête du journal. Exemples Combinaison de comptes incorrectePièces justificatives insuffisantesDépasse le budget
	Service de l’utilisateur UserDepartment	Le service ou l’équipe auquel appartient l’utilisateur ayant exécuté l’activité.
Description Cet attribut fournit un contexte organisationnel en reliant une activité à un service précis, tel que « Finance », « Opérations comptables » ou « Audit interne ». Il est généralement dérivé des données de référence des utilisateurs. L’analyse par service de l’utilisateur permet d’identifier les goulots d’étranglement entre services, de comparer la performance des équipes et de comprendre les différences d’exécution du processus au sein de l’organisation. Elle est utile pour l’allocation des ressources et les initiatives d’amélioration ciblées. Pourquoi c’est important Fournit un contexte organisationnel, permet d’analyser la performance par équipe ou par service et met en évidence les inefficacités entre fonctions. Où les obtenir Cette information ne figure généralement pas dans les tables de transactions. Elle doit être obtenue en reliant UserName à une table de référence des utilisateurs ou aux données d’un système RH. Exemples Comptabilité généraleReporting financierComptes fournisseurs
	Source de l’écriture comptable JournalSource	Le sous-livre ou le système source à l’origine de l’écriture comptable, tel que « 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-livres tels que les comptes fournisseurs, les comptes clients ou les immobilisations. La source de l’écriture est un attribut essentiel pour analyser l’automatisation. Elle permet de distinguer les écritures manuelles des écritures générées par le système et contribue au KPI « Taux d’écritures comptables automatisées ». Les processus associés à différentes sources présentent souvent des écarts importants en matière de complexité et d’efficacité. Pourquoi c’est important Distingue les écritures manuelles des écritures automatisées, ce qui est essentiel pour mesurer les taux d’automatisation et analyser les différences entre les processus. Où les obtenir Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé JE_SOURCE. Exemples ManuelDettes fournisseursActifsCréances clients
	Utilisateur UserName	L’utilisateur qui a exécuté l’activité, par exemple en créant, en approuvant ou en comptabilisant l’écriture comptable.
Description Cet attribut identifie le salarié ou l’utilisateur système responsable de l’exécution d’une activité. Il est essentiel pour comprendre la répartition de la charge de travail, évaluer la performance et identifier les goulots d’étranglement individuels. Dans l’analyse, UserName permet de filtrer les processus par utilisateur, de comparer l’efficacité des utilisateurs et d’étudier les causes des retards ou des erreurs. Il alimente directement des Dashboards tels que « Charge de travail et efficacité des utilisateurs entre les équipes » et des KPI comme le « User Journal Bottleneck Index ». Pourquoi c’est important Attribue la responsabilité des étapes du processus et permet d’analyser la charge de travail des utilisateurs, la performance individuelle et les besoins de formation. Où les obtenir Présent dans des tables de transactions telles que GL_JE_HEADERS, par exemple CREATED_BY et LAST_UPDATED_BY, ainsi que dans les tables de piste d’audit associées. Exemples john.doesusan.smithautoprocess_user
	Comptabilisation dans les délais IsOnTimePosting	Indicateur calculé qui prend la valeur true si l’écriture a été comptabilisée à la date cible ou avant celle-ci.
Description Cet attribut booléen est calculé en comparant l’horodatage de l’activité « Écriture comptable comptabilisée » à la « Date cible de comptabilisation ». Si la comptabilisation intervient à la date cible ou avant, la valeur est « true » ; sinon, elle est « false ». Cet attribut contribue directement au KPI « Taux de comptabilisation des écritures comptables dans les délais » en simplifiant son calcul. Il permet de filtrer et d’analyser facilement les écritures en retard afin d’identifier les causes fréquentes des délais, comme certaines catégories d’écritures ou certains approbateurs. Pourquoi c’est important Fournit un résultat binaire clair sur la performance de comptabilisation et simplifie l’analyse du respect des délais ainsi que des causes profondes des retards. Où les obtenir Cet attribut est calculé par l’outil de Process Mining. Il nécessite l’attribut « TargetPostingDate » et l’horodatage de l’activité « Écriture comptable comptabilisée ». Exemples truefalse
	Date cible de comptabilisation TargetPostingDate	Date prévue à laquelle l’écriture comptable doit être comptabilisée au plus tard.
Description La date cible de comptabilisation correspond à l’échéance de comptabilisation d’une écriture dans le grand livre. Elle est souvent déterminée par des accords de niveau de service (SLA) ou par le calendrier de clôture mensuelle. Elle sert de référence pour mesurer la performance. Cet attribut est essentiel au calcul du KPI « Taux de comptabilisation des écritures comptables dans les délais ». En comparant la date réelle de comptabilisation à cette date cible, le système peut automatiquement signaler les écritures traitées dans les délais ou en retard et fournir une mesure claire du respect du calendrier. Pourquoi c’est important Définit l’accord de niveau de service ou l’échéance de comptabilisation et permet de calculer les KPI de performance dans les délais. Où les obtenir Ce champ peut ne pas être standard. Il peut être calculé à 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
	Délai de traitement de bout en bout EndToEndCycleTime	Durée totale calculée entre la création d’une écriture comptable et son rapprochement final.
Description Cette mesure représente le temps total passé par une écriture comptable dans l’ensemble du processus, depuis le premier événement « Écriture comptable créée » jusqu’à l’événement final « Écriture comptable rapprochée ». Elle offre une vue globale de la performance du processus. Il s’agit d’un KPI principal pour mesurer l’efficacité globale du processus. Il est utilisé dans les Dashboards de suivi des tendances afin de mesurer l’impact des initiatives d’amélioration au fil du temps et fournit une référence pour évaluer toutes les évolutions du processus. Pourquoi c’est important Fournit une mesure globale de la santé et de l’efficacité du processus et constitue un indicateur essentiel pour le reporting destiné aux dirigeants. Où les obtenir Cette mesure est calculée par la plateforme de Process Mining comme la différence entre les horodatages du premier et du dernier événement de chaque cas. Exemples P10DT5HP4DT12HP22D
	Devise CurrencyCode	Code de la devise associée au montant de l’écriture comptable, par exemple USD, EUR ou GBP.
Description Le code devise précise la devise des montants financiers de l’écriture comptable. Il est indispensable pour les organisations internationales qui effectuent des transactions dans plusieurs devises. Cet attribut garantit une interprétation correcte des valeurs financières. Il permet de filtrer les données par devise et est nécessaire pour toute analyse comparant ou agrégeant des montants monétaires entre différentes régions. Pourquoi c’est important Fournit le contexte nécessaire à l’interprétation des montants financiers et permet de mener des analyses propres à chaque devise. Où les obtenir Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé CURRENCY_CODE. Exemples USDEURGBPJPY
	Fait l’objet d’une reprise IsRework	Indicateur calculé qui prend la valeur true si l’écriture comptable a fait l’objet d’un cycle de rejet et de correction.
Description Cet attribut booléen est calculé pour identifier les cas ayant fait l’objet d’une reprise. Il prend généralement la valeur « true » pour toute activité qui suit un événement « Écriture comptable rejetée », comme « Écriture comptable corrigée et soumise à nouveau ». L’indicateur de reprise est particulièrement utile pour l’analyse, car il permet de quantifier facilement le volume et l’impact des boucles de reprise. Il contribue directement au KPI « Taux moyen de reprise des écritures comptables » et facilite la comparaison du flux et de la durée des cas repris avec ceux traités correctement dès la première tentative. Pourquoi c’est important Signale directement les cas ayant suivi des boucles de reprise inefficaces et facilite la mesure de la fréquence et de l’impact des défaillances du processus. Où les obtenir Cet attribut n’est pas disponible dans le système source. Il est calculé dans l’outil de Process Mining en analysant la séquence des activités de chaque cas. Exemples truefalse
	Heure de fin EndTime	L’horodatage indiquant le moment où une activité précise a été terminée.
Description End Time indique la fin d’une activité. Alors que Start Time enregistre son début, End Time fournit le point de clôture et permet de calculer précisément le temps de traitement de cette étape. Cet attribut est essentiel pour calculer les temps de traitement des activités, un indicateur central pour identifier les goulots d’étranglement et mesurer l’efficacité des ressources. Par exemple, la différence entre End Time et Start Time pour l’activité « Écriture comptable examinée » correspond au temps réellement consacré à la tâche par l’examinateur. Pourquoi c’est important Il permet de calculer la durée réelle ou le temps de traitement de chaque activité, ce qui est essentiel pour identifier les problèmes d’efficacité. Où les obtenir Comme Start Time, cette information se trouve souvent dans les tables de piste d’audit ou peut être déduite du Start Time de l’activité suivante du processus. Exemples 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Indicateur d’extourne ReversalIndicator	Indicateur précisant si l’écriture comptable constitue l’extourne d’une autre écriture.
Description Cet attribut booléen identifie les écritures comptables créées pour extourner une écriture précédemment comptabilisée. Les extournes constituent un type particulier d’écriture, qui suit souvent un processus distinct et parfois problématique. L’analyse de cet indicateur est essentielle au Dashboard « Performance du processus d’extourne des écritures comptables ». Elle permet d’isoler les processus d’extourne afin d’en mesurer la fréquence, les causes et les délais de traitement, et d’identifier les problèmes sous-jacents des écritures initiales qui ont rendu l’extourne nécessaire. Pourquoi c’est important Aide à isoler et à analyser le processus d’extourne, souvent révélateur d’erreurs ou de problèmes dans la transaction initiale. Où les obtenir Il peut s’agir d’un indicateur spécifique de la table GL_JE_HEADERS, tel que ACCRUAL_REV_FLAG, ou d’un élément identifié grâce aux liens vers l’écriture d’origine faisant l’objet de l’extourne. 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 identifie le grand livre auquel l’écriture comptable appartient. Dans les organisations qui regroupent plusieurs entités juridiques ou qui doivent répondre à différentes exigences de reporting, plusieurs grands livres peuvent coexister, par exemple un grand livre principal pour la comptabilité du groupe et des grands livres secondaires pour le reporting légal local. Cet attribut est essentiel pour filtrer et comparer les processus entre différentes entités juridiques ou unités opérationnelles. Il garantit que les analyses sont menées dans le bon contexte organisationnel, ce qui est particulièrement important pour la conformité financière et le reporting. Pourquoi c’est important Permet de filtrer et de comparer l’analyse des processus entre différentes entités juridiques ou référentiels comptables, ce qui est indispensable dans les grandes organisations. Où les obtenir Présent dans la table GL_JE_HEADERS, généralement via un LEDGER_ID pouvant être joint à GL_LEDGERS pour obtenir le nom. Exemples Grand livre principal des États-UnisGrand livre statutaire du Royaume-UniGrand livre de consolidation mondial
	Période comptable AccountingPeriod	Période fiscale à laquelle l’écriture comptable est comptabilisée, par exemple « Jan-24 ».
Description La période comptable précise la période financière au cours de laquelle la transaction est reconnue. Elle constitue un élément fondamental de tout reporting et de toute analyse financière. Dans le Process Mining, cet attribut est essentiel à l’analyse des tendances. Il permet de comparer les performances du processus, comme les délais de traitement ou les taux de rejet, entre différents mois ou trimestres. Il aide à repérer les effets saisonniers, par exemple l’augmentation de la charge de travail lors de la clôture mensuelle, et à mesurer l’impact des améliorations au fil du temps. Pourquoi c’est important Permet d’analyser l’évolution des KPI dans le temps, de mesurer les progrès du processus et d’identifier les tendances saisonnières, comme la pression liée à la clôture mensuelle. Où les obtenir Disponible dans la table GL_JE_HEADERS, généralement dans un champ nommé PERIOD_NAME. Exemples Jan-24Fév-24Mars-24
	Statut de comptabilisation PostingStatus	Statut actuel de comptabilisation de l’écriture comptable, par exemple « Non comptabilisée » ou « Comptabilisée ».
Description Cet attribut reflète l’état actuel de l’écriture comptable au regard de sa comptabilisation dans le grand livre. Il indique à quelle étape du cycle de vie se trouve l’écriture, notamment pour les cas en cours de traitement. Le statut de comptabilisation est essentiel au Dashboard « Suivi en temps réel du statut des écritures comptables », qui fournit une vue instantanée de toutes les écritures actives. Il permet de surveiller les arriérés d’écritures non comptabilisées et d’identifier les retards dans les dernières étapes du processus. Pourquoi c’est important Indique l’état actuel d’une écriture, ce qui est essentiel pour surveiller les arriérés et suivre le statut des écritures en cours de traitement. Où les obtenir Disponible dans la table GL_JE_HEADERS, généralement dans une colonne telle que STATUS ou POSTING_STATUS. Exemples ComptabiliséNon comptabiliséErreur

Obligatoire Recommandé Facultatif

Record to Report - Activités liées aux écritures comptables

Voici les principales étapes et les jalons à enregistrer dans votre journal d’événements pour découvrir précisément le processus d’écriture comptable.

5 Recommandé 7 Facultatif

	Activité	Description
	Écriture comptable approuvée	L’approbateur désigné a officiellement approuvé l’écriture comptable et en a confirmé l’exactitude et la validité. Il s’agit de la dernière étape du flux de travail d’approbation, qui ouvre la voie à la comptabilisation.
Pourquoi c’est important Cette étape marque la fin du processus d’approbation. Le temps écoulé entre la soumission et l’approbation constitue un KPI important pour mesurer l’efficacité du flux de travail et repérer les goulots d’étranglement liés aux approbations. Où les obtenir Cet événement est déduit d’un changement de statut dans la table GL_JE_HEADERS, lorsque la valeur APPROVAL_STATUS_CODE est mise à jour sur « APPROVED ». Les tables du flux de travail contiennent l’identité de l’approbateur et l’horodatage correspondants. Collecte Suivez l’horodatage auquel APPROVAL_STATUS_CODE dans GL_JE_HEADERS change pour prendre la valeur « APPROVED ». Type d’événement inferred
	Écriture comptable comptabilisée	Les données financières de l’écriture comptable ont été enregistrées avec succès dans le General Ledger. Les débits et les crédits sont désormais intégrés aux soldes des comptes.
Pourquoi c’est important Il s’agit d’une étape essentielle, qui correspond à l’intégration de l’écriture dans les documents financiers officiels. Elle est indispensable pour mesurer le taux de comptabilisation dans les délais et le délai total entre la création et la comptabilisation. Où les obtenir 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 » (Posted). La table GL_JE_BATCHES contient également un statut de comptabilisation. Collecte Suivez l’horodatage auquel STATUS dans GL_JE_HEADERS prend la valeur « P ». Type d’événement inferred
	Écriture comptable créée	Cette activité marque le début du processus de saisie d’une écriture comptable. 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 examen ou approbation.
Pourquoi c’est important Il s’agit de l’événement de début principal du processus. L’analyse du délai entre cette activité et les étapes suivantes permet de mesurer l’efficacité de la saisie initiale des données et la durée globale du cycle du processus. Où les obtenir Cet événement est généralement déduit de l’horodatage de création figurant dans la table GL_JE_HEADERS pour un Journal Entry ID donné. L’utilisateur ayant créé l’enregistrement est également disponible dans cette table. Collecte Utilisez CREATION_DATE dans la table GL_JE_HEADERS. Type d’événement inferred
	Écriture comptable rapprochée	L’écriture comptable a été rapprochée et lettrée dans le cadre du rapprochement des comptes en fin de période. Cela confirme que la transaction correspond aux autres données financières, telles que les relevés bancaires.
Pourquoi c’est important Cette activité constitue le véritable point final du cycle de vie de l’écriture. Le délai entre la comptabilisation et le rapprochement est un KPI essentiel pour évaluer l’efficacité du processus de clôture financière. Où les obtenir 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 General Ledger lui-même. Il est déduit d’un changement de statut de l’enregistrement de rapprochement lié à l’écriture. Collecte Mettez en correspondance les données de l’écriture avec les mises à jour du statut de rapprochement provenant des tables ARCS ou FCCS. Type d’événement inferred
	Écriture comptable soumise pour approbation	Cette activité intervient lorsque l’utilisateur soumet officiellement l’écriture comptable terminée au flux de travail d’approbation. L’écriture passe alors de l’état de brouillon ou d’incomplétude à l’état d’approbation en attente.
Pourquoi c’est important Il s’agit d’une étape essentielle qui lance le décompte du cycle d’approbation et permet d’identifier les goulots d’étranglement. Elle sépare la phase de saisie des données de la phase d’examen et d’approbation. Où les obtenir Cet événement est déduit d’un changement de statut dans la table GL_JE_HEADERS, notamment lorsque APPROVAL_STATUS_CODE prend une valeur telle que « REQUIRED » ou « INITIATED ». L’horodatage de soumission peut également être enregistré. Collecte Suivez l’horodatage auquel APPROVAL_STATUS_CODE dans GL_JE_HEADERS change pour indiquer la soumission. Type d’événement inferred
	Comptabilisation de l’écriture initiée	Le processus de comptabilisation de l’écriture approuvée dans le General Ledger a commencé. Il peut s’agir d’une étape automatisée ou manuelle qui place l’écriture dans une file d’attente pour traitement par le programme de comptabilisation.
Pourquoi c’est important Cette activité distingue l’approbation du processus technique de comptabilisation. Des délais entre l’approbation et le lancement de la comptabilisation peuvent signaler des problèmes de planification ou des contraintes de ressources dans le moteur de comptabilisation. Où les obtenir 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 demande concurrente de comptabilisation associée au lot d’écritures. Collecte Identifiez l’heure de soumission de la demande du programme General Ledger Posting pour le lot d’écritures concerné. Type d’événement inferred
	Comptabilisation vérifiée	Cette étape de vérification postérieure à la comptabilisation consiste pour un utilisateur ou un système à confirmer que l’écriture a été correctement comptabilisée et que les soldes sont conformes aux attentes. Il s’agit souvent d’un contrôle manuel.
Pourquoi c’est 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 mettre en évidence des possibilités d’automatisation des processus de vérification. Où les obtenir Il est peu probable qu’il s’agisse d’un événement explicite dans Oracle Fusion. Il faudrait le déduire d’autres actions, comme 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 des fonctionnalités standard. Collecte 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 flexfield descriptif. Type d’événement inferred
	Contrepassation de l’écriture traitée	Une écriture de contrepassation a été créée et comptabilisée afin d’annuler l’impact financier de l’écriture d’origine au cours d’une période ultérieure. Il s’agit d’une opération courante pour les charges à payer.
Pourquoi c’est important Le suivi des contrepassations permet d’identifier les types d’écritures fréquemment contrepassés et d’analyser l’efficacité du processus de contrepassation lui-même. Il peut révéler des problèmes de gestion des charges à payer. Où les obtenir Cet événement est déduit de l’identification d’une nouvelle écriture explicitement liée à l’écriture d’origine comme sa contrepassation. La table GL_JE_HEADERS contient des champs tels que REVERSAL_PERIOD et REVERSAL_FLAG, qui permettent d’identifier et de relier ces écritures. Collecte Identifiez la date de création et la date de comptabilisation de la nouvelle écriture dont l’en-tête indique qu’elle contrepasse l’écriture d’origine. Type d’événement inferred
	Écriture comptable corrigée et soumise à nouveau	Après le rejet d’une écriture comptable, son créateur apporte les corrections nécessaires et la soumet à nouveau pour approbation. Cette activité marque le début d’un nouveau cycle d’approbation pour la même écriture.
Pourquoi c’est important Le suivi des reprises est essentiel pour comprendre les inefficacités du processus. Associée à l’activité « Écriture comptable rejetée », cette activité permet de mesurer la durée et la fréquence des reprises. Où les obtenir Il s’agit d’un nouvel événement « Écriture comptable soumise pour approbation » pour une écriture qui se trouvait auparavant à l’état « REJECTED ». Il est identifié en analysant la séquence des changements de statut pour un même Journal Entry ID. Collecte Identifiez un horodatage de soumission qui intervient après un événement de rejet pour le même identifiant de cas. Type d’événement inferred
	Écriture comptable examinée	Cette étape d’examen peut intervenir avant le processus d’approbation officiel ou en faire partie. Elle correspond à une vérification effectuée par un collègue ou un responsable afin de s’assurer de l’exactitude et de la conformité de l’écriture avant son transfert à l’approbateur final.
Pourquoi c’est important L’isolation de cette activité permet de distinguer les délais d’examen préliminaire des délais d’approbation finale. Elle peut révéler des goulots d’étranglement dissimulés lorsque l’étape d’examen est informelle, mais chronophage. Où les obtenir Il peut s’agir d’une étape explicite d’un flux de travail d’approbation à plusieurs niveaux, enregistrée dans les tables d’historique du flux de travail. Si elle est informelle, elle n’est pas enregistrée. Elle peut être déduite lorsqu’une action précise de l’utilisateur est consignée avant la décision d’approbation finale. Collecte Analysez les tables d’historique du flux de travail afin d’identifier les étapes intermédiaires d’approbation ou d’examen avant le statut final « Approved ». Type d’événement inferred
	Écriture comptable rejetée	Un approbateur a examiné l’écriture comptable et l’a rejetée en raison d’erreurs, de pièces justificatives manquantes ou de non-respect des règles. Cette action renvoie l’écriture à son créateur pour correction.
Pourquoi c’est important Cette activité est essentielle pour analyser les boucles de reprise, les taux de rejet et les indicateurs de conformité dès la première soumission. Une fréquence élevée de rejets révèle souvent des problèmes de qualité des données ou de formation. Où les obtenir Cet événement est déduit d’un changement de statut dans la table GL_JE_HEADERS, lorsque la valeur APPROVAL_STATUS_CODE est mise à jour sur « REJECTED ». L’historique du flux de travail enregistre l’utilisateur et l’horodatage associés à cette action. Collecte Suivez l’horodatage auquel APPROVAL_STATUS_CODE dans GL_JE_HEADERS prend la valeur « REJECTED ». Type d’événement inferred
	Pièces justificatives jointes	Cette activité correspond à l’ajout de pièces justificatives, telles que des factures ou des feuilles de calcul, à l’écriture comptable. Elle permet souvent de fournir aux auditeurs et aux approbateurs le contexte et les éléments nécessaires.
Pourquoi c’est important Le suivi de cette activité permet de déterminer si les retards sont dus à l’absence de documents. Il fournit également des indications sur la conformité et sur l’exhaustivité des écritures comptables avant leur entrée dans le flux de travail d’approbation. Où les obtenir Cette activité peut être difficile à suivre comme événement distinct. Elle peut être déduite des horodatages figurant dans des tables de pièces jointes telles que FND_ATTACHED_DOCUMENTS, liées à l’enregistrement de l’écriture dans GL_JE_HEADERS. Collecte Déduisez l’événement 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 Reports and Analytics : Connectez-vous à Oracle Fusion Financials. Dans le menu Navigator, sélectionnez Tools, puis Reports and Analytics. Il s’agit de l’espace central pour créer et gérer toutes les analyses et tous les rapports.
Créez un modèle de données BI Publisher : Plutôt que de commencer par une analyse OTBI, il est plus efficace, pour ce type d’extraction de journal d’événements, de créer directement un modèle de données BI Publisher. 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 du modèle de données, cliquez sur l’icône « + » pour ajouter un nouveau Data Set, 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 l’intégralité du script SQL présenté dans la section Query ci-dessous et collez-le dans la zone de texte SQL Query. Cette 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étectera automatiquement. Vous devez les configurer comme paramètres, en définissant les types de données appropriés, Date ou Text, ainsi que les valeurs par défaut si nécessaire. Vous pourrez ainsi exécuter le rapport de manière flexible.
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 du rapport, 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 la mise en page « Table ». Il est essentiel de faire glisser toutes les colonnes du modèle de données dans le tableau afin qu’elles soient incluses dans l’export. Aucun formatage complexe n’est nécessaire.
Définissez CSV comme format de sortie par défaut : Accédez au lien « View a List » dans l’éditeur du rapport. Dans la section « Output Formats », vérifiez que « CSV » est sélectionné. Il est recommandé de désélectionner tous les autres formats pour simplifier la planification. Enregistrez le rapport.
Planifiez l’extraction automatisée 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 distribution : 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 distribution du fichier vers un emplacement de serveur de contenu (UCM) ou un serveur SFTP externe afin d’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é depuis la destination configurée. Vérifiez que les en-têtes de colonnes correspondent aux exigences d’ingestion de ProcessMind : JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. Le fichier est alors prêt à être importé.

Configuration

Source de données : la requête doit être exécutée sur la source de données « Oracle BI EE » dans BI Publisher, qui se connecte aux vues de la base transactionnelle sous-jacente utilisées par OTBI.
Principaux domaines fonctionnels, à titre de référence : la logique de la requête repose principalement sur les données du domaine « General Ledger - Journals Real Time ». Elle joint également, sur le plan logique, des données qui se trouveraient dans « HCM - Workforce Management - Worker Assignment Real Time » pour les informations utilisateur, ainsi que, potentiellement, dans les domaines du flux de travail pour l’historique des approbations.
Filtrage de la période : il est essentiel de limiter les données à une période gérable. La requête inclut les paramètres :start_date et :end_date. Nous recommandons d’extraire trois à six mois de données pour une première analyse. Le filtre s’applique à la date de création du journal.
Filtrage du grand livre : utilisez le paramètre :ledger_name pour limiter l’extraction à un grand livre principal précis. Extraire tous les grands livres en une seule fois peut produire des fichiers extrêmement volumineux et entraîner des problèmes de performances.
Prérequis : l’utilisateur qui crée et planifie le rapport doit disposer des rôles BI appropriés, tels que « BI Administrator » ou « BI Author ». En outre, son profil de sécurité des données doit lui donner accès aux grands livres et aux unités opérationnelles interrogés.
Planification : pour obtenir de bonnes performances et éviter de perturber les utilisateurs du système, planifiez l’extraction en dehors des heures de pointe, par exemple pendant la nuit.

a 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 le bouton Create, puis sélectionnez Data Model. L’éditeur du modèle de données s’ouvre.
Définissez le jeu de données de la requête SQL : Dans l’éditeur du modèle de données, cliquez sur l’icône plus dans l’onglet Diagram, puis sélectionnez SQL Query. Dans la nouvelle boîte de dialogue, donnez un nom au 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 des paramètres pour la période (p_start_date et p_end_date). Oracle BI Publisher les détectera 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 situé en haut à droite de l’éditeur du modèle de données. L’assistant de création du rapport s’ouvre.
Configurez la mise en page du rapport : Dans l’assistant, sélectionnez l’option permettant d’utiliser le modèle de données actuel. Choisissez la mise en page « 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 rapport dans le même dossier que le modèle de données. Donnez-lui un nom explicite, tel que « Journal Entry Event Log Report ».
Définissez le format de sortie par défaut : Modifiez le rapport et accédez à l’onglet « Viewing ». Dans « Output Formats », vérifiez que CSV est sélectionné et définissez-le de préférence comme format par défaut. La sortie sera ainsi directement compatible avec l’utilisation prévue.
Exécutez et exportez : Ouvrez le rapport. Vous devrez saisir les paramètres de date de début et de fin. 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 fichier du journal d’événements.
Préparez l’import : 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 leur importation dans la plateforme ProcessMind.

Configuration

Prérequis : L’utilisateur 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 General Ledger, 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 être configuré pour utiliser la connexion à la base applicative FUSIONDB.
Paramètres de période : La requête utilise les paramètres p_start_date et p_end_date pour définir la fenêtre d’extraction. Il est recommandé de commencer par une période de trois à six mois afin de préserver les performances.
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. Le filtrage par LEDGER_ID ou LEGAL_ENTITY_ID est essentiel pour maîtriser le volume de données.
Considérations de performance : L’exécution de cette requête sur une grande base de production peut mobiliser des ressources importantes. Planifiez le rapport pendant les heures creuses afin de limiter son impact sur les performances du système.
Format de sortie : Le rapport doit être configuré pour produire un fichier CSV. Ce format structuré convient à l’ingestion dans les outils de Process Mining.

a Exemple de requête sql

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Étapes

Prérequis : Vérifiez que Python 3 est installé avec les bibliothèques requests et pandas. Vous aurez besoin d’un compte utilisateur 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 nouveau 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. Définissez également les paramètres d’extraction, notamment les dates de début et de fin de la requête.
Authentifiez-vous : Le script utilise l’authentification Basic. La bibliothèque requests se charge d’encoder 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 gérer la pagination à l’aide des paramètres offset et limit. La fonction effectue des appels successifs jusqu’à avoir récupéré toutes les écritures comprises dans la période indiquée.
Construisez la requête API : Utilisez le paramètre q de la requête API pour filtrer les journaux 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 commencer à récupérer les données depuis le point de terminaison .../fscmRestApi/resources/11.13.18.05/journals. La fonction renverra la liste complète des écritures.
Traitez et transformez les données : Parcourez chaque écriture renvoyée par l’API. Pour chaque écriture, générez plusieurs lignes d’événements correspondant aux différentes activités métier (Journal Entry Created, Journal Entry Approved, etc.). Utilisez les champs de date et les codes de statut de la réponse API (CreationDate, PostedDate, ApprovalStatus, etc.) pour créer ces événements distincts.
Structurez le journal d’événements : À mesure que chaque ligne d’événement est générée, stockez-la sous forme de dictionnaire dans une liste. Cette liste constituera les données brutes de votre journal d’événements.
Créez le DataFrame : Une fois toutes les écritures traitées, convertissez la liste de dictionnaires d’événements en DataFrame Pandas afin de faciliter sa manipulation.
Finalisez les colonnes : Sélectionnez et renommez les colonnes du DataFrame afin de respecter le 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 Basic.
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 General Ledger.
Filtre de période : Le script doit être configuré avec une start_date et une end_date afin de limiter le périmètre de l’extraction. Pour une première analyse, une période de trois à six mois est recommandée. Pour une utilisation récurrente, 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 est généralement efficace, car elle équilibre 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 journaux via l’API REST, par exemple le rôle General Accountant ou un rôle personnalisé offrant des autorisations équivalentes.

a Exemple de requête python

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

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

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

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

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

    return all_journals

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

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

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

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

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

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

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

    return pd.DataFrame(event_log)

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

Étapes

Vérifiez que BI Cloud Connector, les domaines fonctionnels General Ledger ou les Public View Objects Oracle Fusion Financials requis, ainsi que les autorisations nécessaires dans le système source, sont disponibles dans votre environnement. Confirmez auprès de votre administrateur Oracle la cible de distribution BICC configurée et les identifiants permettant d’y accéder.
Dans la console BI Cloud Connector, identifiez les Public View Objects contenant les en-têtes et lignes de journaux, 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 ces valeurs génériques dans le script d’extraction 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 fiable de dernière mise à jour est disponible. Pour le chargement initial, utilisez une période contrôlée de trois à six mois, ou toute autre période comptable approuvée.
Configurez BICC pour distribuer les fichiers extraits vers l’emplacement de stockage cloud désigné. Vérifiez le format du fichier, le séparateur, l’encodage des caractères, la compression, le partitionnement, la convention de nommage et la planification de la distribution. Conservez le watermark d’extraction ou l’horodatage de la dernière extraction réussie.
Récupérez les fichiers distribués dans la zone de staging approuvée. Chargez chaque fichier source dans la table ou la vue de staging correspondante. Utilisez les correspondances exactes entre objets et attributs sources documentées pour votre environnement. Ne supposez pas qu’un Public View Object possède la même structure qu’une table de base de données sous-jacente.
Normalisez les horodatages dans un fuseau horaire unique et convertissez les horodatages sources vers un type cohérent. Conservez l’horodatage de mise à jour source dans LastDataUpdate. Convertissez les identifiants sources et les attributs d’activité vers les noms de sortie utilisés par ProcessMind.
Exécutez la requête ci-dessous après avoir remplacé chaque valeur générique par le nom réel de l’objet de staging ou de l’attribut correspondant. La requête crée explicitement une ligne de 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 présents dans chaque ligne de sortie. Examinez les événements en double, l’ordre des horodatages, les journaux rejetés puis soumis à nouveau, les relations d’extourne et les enregistrements dont certains attributs facultatifs sont manquants.
Exportez le résultat dans un fichier délimité ou dans tout autre format pris en charge par ProcessMind. Incluez exactement les noms de colonnes 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 sur les objets de vue publique General Ledger nécessaires aux en-têtes et lignes de journal, à l’historique des approbations ou du flux de travail, aux pièces jointes, aux données de comptabilisation, de rapprochement et d’extourne. Les noms et attributs exacts des objets doivent être confirmés dans le catalogue BICC de votre environnement.
Utilisez une période d’extraction initiale de trois à six mois. N’élargissez cette période qu’après avoir validé le volume, la capacité de stockage, la durée d’extraction et le temps de traitement en aval.
Appliquez les filtres approuvés concernant 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é lorsqu’il est disponible, la catégorie et la source du journal, le type de document lorsqu’il est disponible, ainsi que le statut du journal. Utilisez uniquement les filtres pris en charge par les objets de vue publique 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é. Ajoutez, si nécessaire, une courte période de chevauchement pour tenir compte des mises à jour arrivées tardivement, puis dédupliquez 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 jeux de données volumineux, partitionnez les données par période comptable, grand livre, entité juridique ou autre attribut de partitionnement BICC pris en charge. Évitez les extractions historiques sans restriction pendant les heures ouvrées.
Conservez les horodatages sources et les horodatages de mise à jour de la source 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, l’accès à l’environnement de préparation et l’autorisation de consulter les données General Ledger et du flux de travail requises.
Vérifiez que les modules Oracle Fusion Financials requis, la configuration du flux de travail, le stockage des pièces jointes, les processus de comptabilisation et les sources de données de rapprochement sont activés lorsque ces activités sont attendues.
Ne considérez pas l’absence d’un enregistrement source comme la preuve qu’une activité n’a pas eu lieu. La sortie BICC dépend des objets de vue publique sélectionnés, des filtres, du calendrier d’actualisation, de la durée de conservation et de l’historique disponible.

a 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 template pour transformer vos données Oracle Fusion Journal Entry en analyses concrètes et accélérer 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 votre processus Record to Report - Journal Entry

Réduisez de 30 % le délai de traitement de Journal Entry et optimisez vos opérations financières.

Démarrer l’essai gratuit

Aucune carte bancaire requise, activez votre essai dès maintenant.

Votre template de données Record to Report - Journal Entry

Votre template de données Record to Report - Journal Entry

Record to Report - Attributs des écritures comptables

Record to Report - Activités liées aux écritures comptables

Guides d’extraction

Export de rapports Oracle OTBI et BI Publisher

Étapes

Configuration

a Exemple de requête sql

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

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l’API REST Oracle Fusion Financials

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Accélérez dès aujourd’hui votre processus Record to Report - Journal Entry

Votre template de données Record to Report - Journal Entry

Votre template de données Record to Report - Journal Entry

Record to Report - Attributs des écritures comptables

Record to Report - Activités liées aux écritures comptables

Guides d’extraction

Export de rapports Oracle OTBI et BI Publisher

Étapes

Configuration

a Exemple de requête sql

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

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l’API REST Oracle Fusion Financials

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Accélérez dès aujourd’hui votre processus Record to Report - Journal Entry

Nous attachons de l’importance à votre confidentialité