Votre modèle de données Record to Report - Journal Entry
Votre modèle de données Record to Report - Journal Entry
- Attributs recommandés pour une analyse complète
- Activités clés des écritures comptables à suivre
- Conseils pratiques pour extraire les données de SAP ECC
Record to Report - Attributs des écritures comptables
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | Horodatage indiquant le moment où une activité ou un événement précis s’est produit pour l’écriture comptable. | ||
| Description L’heure de l’événement fournit la date et l’heure exactes de chaque activité du processus d’écriture comptable. Ces données sont essentielles au calcul de toutes les métriques temporelles, telles que les durées de cycle, les durées de traitement et les délais entre les étapes. La source de cet horodatage varie selon l’activité : il peut s’agir de la date et de l’heure de création du document (CPUDT/CPUTM) ou des horodatages de modification issus des journaux (CDHDR-UDATE/UTIME). Dans l’analyse, l’heure de l’événement sert à classer les événements par ordre chronologique et constitue la base de la carte de processus. Elle est indispensable au calcul de tous les KPI liés au temps, tels que la durée moyenne du cycle d’une écriture comptable, la durée moyenne d’approbation et le délai entre l’approbation et la comptabilisation. Pourquoi c’est important Cet horodatage constitue la base de toutes les analyses liées au temps et permet de calculer les durées de cycle, les délais et les goulots d’étranglement. Où les obtenir Provient de différents champs selon l’activité, principalement de l’horodatage de création (CPUDT, CPUTM) de BKPF ou des horodatages des documents de modification (UDATE, UTIME) de CDHDR. Exemples 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| Identifiant d’écriture comptable JournalEntryId | Identifiant unique d’un document de comptabilité financière, combinant le code société, le numéro de document et l’exercice. | ||
| Description L’identifiant d’écriture comptable est l’identifiant de cas principal utilisé pour suivre le cycle de vie d’une écriture comptable. Il s’agit d’une clé composite, généralement constituée par la concaténation du code société (BUKRS), du numéro de document (BELNR) et de l’exercice (GJAHR), afin de garantir son unicité dans l’ensemble du système SAP. Dans l’analyse des processus, cet identifiant relie toutes les activités associées, telles que la création, la mise en attente, la soumission, l’approbation, le rejet et la comptabilisation. En suivant cet identifiant, vous pouvez reconstituer le parcours de bout en bout de chaque écriture comptable, mesurer les durées de cycle et identifier les écarts ou les goulots d’étranglement propres à certaines écritures. Pourquoi c’est important Il s’agit de la clé essentielle pour suivre une écriture comptable de sa création à sa comptabilisation finale, et ainsi permettre l’analyse des processus de bout en bout et la comparaison des variantes. Où les obtenir Il s’agit d’un attribut dérivé, généralement obtenu par concaténation de champs de la table BKPF : code société (BUKRS), numéro de document (BELNR) et exercice (GJAHR). Exemples 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Nom de l’activité ActivityName | Nom de l’activité métier ou de l’événement survenu à un moment précis du processus d’écriture comptable. | ||
| Description Le nom de l’activité décrit une étape précise du cycle de vie d’une écriture comptable, telle que « Journal Entry Created », « Journal Entry Approved » ou « Journal Entry Posted ». Cet attribut est généralement dérivé de plusieurs sources SAP, notamment les codes de transaction (TCODE), les journaux de modification des documents, dans les tables CDHDR et CDPOS, ainsi que les champs de statut des documents. L’analyse des activités constitue le cœur du Process Mining. Elle permet de visualiser les cartes de processus, de calculer les délais de transition entre les étapes et d’identifier les boucles de correction, par exemple « Journal Entry Rejected » suivi de « Journal Entry Corrected ». Ces données sont indispensables aux Dashboards consacrés aux durées de cycle, aux taux de correction et aux variantes de processus. Pourquoi c’est important Il définit les étapes de la cartographie du processus et permet ainsi de visualiser, d’analyser et d’optimiser le flux de travail des écritures comptables. Où les obtenir Cet attribut est dérivé de différentes sources, notamment des codes de transaction de BKPF (TCODE), du statut du document et des journaux du flux de travail dans des tables telles que SWW_WI2OBJ, ou encore des documents de modification dans CDHDR et CDPOS. Exemples Écriture comptable crééeÉcriture comptable approuvéeÉcriture comptable rejetéeÉcriture comptable comptabilisée | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant le moment où les données ont été extraites ou actualisées pour la dernière fois depuis le système source. | ||
| Description Cet attribut enregistre la date et l’heure de la dernière extraction de données depuis SAP ECC. Il s’agit d’un champ de métadonnées essentiel pour comprendre l’actualité et la fraîcheur des données analysées. Dans tout Dashboard ou toute analyse de Process Mining, il est essentiel de connaître l’heure de la dernière mise à jour pour que les utilisateurs puissent faire confiance aux données et prendre des décisions éclairées. Cela permet notamment de répondre à la question suivante : « Dans quelle mesure ces informations sont-elles à jour ? » Pourquoi c’est important Informe les utilisateurs de l’actualité des données, afin qu’ils comprennent la période couverte par l’analyse et puissent se fier aux résultats. Où les obtenir Il s’agit d’un champ de métadonnées généré et enregistré par l’outil d’extraction des données ou le processus ETL au moment de l’actualisation des données. Exemples 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Système source SourceSystem | Système à partir duquel les données du processus ont été extraites. | ||
| Description Cet attribut identifie l’origine des données, qui correspond ici à l’instance SAP ECC concernée. Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données. Bien que simple, cet attribut est important dans les environnements comportant plusieurs ERP ou sources de données. Il garantit la traçabilité de l’origine des données et permet de filtrer ou de segmenter l’analyse selon le système source. Pourquoi c’est important Fournit une traçabilité claire des données et est essentiel au suivi de leur qualité, notamment dans les environnements comportant plusieurs systèmes sources. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors de la transformation des données, qui identifie l’instance SAP ECC concernée, par exemple « ECC_PROD_100 ». Exemples SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Code de transaction TransactionCode | Code de transaction SAP utilisé pour créer ou traiter l’écriture comptable. | ||
| Description Le code de transaction, ou T-Code, est l’identifiant unique d’une fonction ou d’un programme précis dans SAP. Pour les écritures comptables, il indique le mode de création de l’écriture, par exemple manuellement (FB01, F-02), par mise en attente (FV50) ou au moyen d’une interface automatisée. Cet attribut est particulièrement utile pour le Dashboard « Manual Activity Optimization ». L’analyse du T-Code permet de distinguer les activités manuelles des activités automatisées, d’identifier les processus manuels les plus chronophages et de repérer les possibilités d’automatisation afin de réduire l’effort manuel et d’améliorer l’efficacité. Pourquoi c’est important Aide à distinguer les processus manuels des processus automatisés, à identifier les possibilités d’automatisation et à standardiser les processus. Où les obtenir Situé dans la table d’en-tête des documents BKPF, champ TCODE. Exemples FB01F-02FV50FBD1 | |||
| Code société CompanyCode | Unité organisationnelle représentant une entité juridique indépendante pour laquelle des états financiers sont préparés. | ||
| Description Le code société est une unité organisationnelle fondamentale de SAP Financials. Il représente une société juridiquement indépendante et constitue un champ clé de l’en-tête du document d’écriture comptable. Cet attribut est essentiel pour segmenter l’analyse des processus par entité juridique. Il permet de comparer la performance des processus, les taux de conformité et les résultats des KPI entre différentes parties de l’entreprise. Il peut notamment aider à déterminer si les retards d’approbation ou les taux élevés d’extourne sont propres à certains codes société. Pourquoi c’est important Permet de filtrer et de comparer la performance des processus entre différentes entités juridiques ou unités opérationnelles de l’organisation. Où les obtenir Situé dans la table d’en-tête des documents BKPF, champ BUKRS. Exemples 10002000US01DE01 | |||
| Date de comptabilisation PostingDate | Date à laquelle la transaction est enregistrée dans le grand livre et qui détermine la période financière concernée. | ||
| Description La date de comptabilisation détermine la période comptable dans laquelle l’écriture comptable est enregistrée. Il s’agit d’un champ de date essentiel du point de vue financier et réglementaire, car il doit respecter le calendrier de clôture des périodes comptables et les exigences applicables. Dans le Process Mining, cette date sert à contrôler la conformité. Le Dashboard « Compliance Adherence Monitoring » et le KPI « Compliance Conformance Rate » utilisent cet attribut pour vérifier que les écritures sont comptabilisées dans la période appropriée. Il peut également servir à analyser l’évolution du volume des écritures comptables au fil du temps. Pourquoi c’est important Essentielle au reporting financier et à l’analyse de conformité, elle garantit que les écritures sont comptabilisées dans la bonne période comptable. Où les obtenir Située dans la table d’en-tête des documents BKPF, champ BUDAT. Exemples 2023-10-312023-11-302024-01-15 | |||
| Est extournée IsReversed | Indicateur booléen précisant si l’écriture comptable a fait l’objet d’une extourne. | ||
| Description Cet indicateur identifie les écritures comptables qui ont ensuite été extournées par un autre document comptable. Dans SAP, un document extourné est associé au document d’extourne, ce qui fournit une piste d’audit claire. Cet attribut est fondamental pour le Dashboard « Journal Entry Reversal Analysis » et le KPI « Journal Entry Reversal Rate ». Il permet d’isoler les écritures extournées afin d’en examiner les causes profondes, telles que des erreurs de saisie ou des traitements comptables incorrects, dans le but de réduire la fréquence des extournes. Pourquoi c’est important Soutient directement l’analyse des extournes en signalant les écritures ultérieurement annulées, ce qui aide à identifier les causes profondes des erreurs et à améliorer l’intégrité des données. Où les obtenir Dérivé du champ du numéro du document d’extourne, STBLG, dans la table BKPF. Si STBLG n’est pas vide, l’indicateur prend la valeur true. Exemples truefalse | |||
| Type de document DocumentType | Classification des documents comptables qui contrôle leur traitement et leur stockage. | ||
| Description Le type de document distingue différentes catégories de transactions métier, telles qu’une écriture au grand livre (SA), une facture fournisseur (KR) ou une comptabilisation d’immobilisation (AA). Il est défini lors de la configuration du système et attribué à chaque écriture comptable. Cet attribut est essentiel à l’analyse, car il permet de segmenter le processus selon la nature de la transaction. Le Dashboard « Journal Entry Throughput by Type » et le KPI « Average Cycle Time by Journal Entry Type » dépendent directement de ce champ. Il permet de déterminer si certains types d’écritures sont davantage sujets aux retards, aux corrections ou aux extournes. Pourquoi c’est important Permet de segmenter l’analyse par type de transaction et d’identifier si les problèmes de processus concernent certains types d’écritures comptables. Où les obtenir Situé dans la table d’en-tête des documents BKPF, champ BLART. Exemples SAKRREAA | |||
| Utilisateur User | Identifiant de l’utilisateur SAP ayant créé ou modifié l’écriture comptable. | ||
| Description Cet attribut enregistre le nom d’utilisateur SAP responsable d’une activité donnée, telle que la création, la mise en attente ou la comptabilisation d’un document. Il provient directement de l’en-tête du document ou des tables de journaux de modification. L’analyse de l’attribut Utilisateur est essentielle pour comprendre la performance des équipes et des personnes. Elle alimente le Dashboard de productivité des utilisateurs en suivant les volumes d’activité et les durées de traitement par utilisateur. Elle permet également d’identifier les personnes impliquées dans les boucles de correction, les extournes ou les écarts de conformité, afin de cibler les formations ou les améliorations du processus. Pourquoi c’est important Identifie l’utilisateur responsable de chaque activité et permet d’analyser la performance, la répartition de la charge de travail et les schémas de correction. Où les obtenir Provient généralement de la table BKPF, champ USNAM pour le créateur, ou de la table CDHDR, champ USERNAME pour l’auteur de la modification. Exemples ABROWNCJONESDSMITH | |||
| Centre de coûts CostCenter | Unité organisationnelle au sein d’un périmètre analytique, représentant un emplacement où des coûts sont engagés. | ||
| Description Le centre de coûts est une donnée de référence essentielle du module Controlling (CO), souvent affectée au niveau du poste d’une écriture comptable. Il sert à suivre les coûts d’un service, d’une fonction ou d’un emplacement donné. L’inclusion du centre de coûts permet d’analyser plus finement le processus de comptabilisation des écritures. Elle peut aider à déterminer si certains services génèrent davantage de reprises, présentent des délais de traitement plus longs ou sont responsables d’un volume plus important de saisies manuelles. Vous obtenez ainsi une vue de l’efficacité du processus par service. Pourquoi c’est important Permet d’analyser la performance du processus par service ou domaine fonctionnel et de localiser les inefficacités. Où les obtenir Situé dans la table des postes de document BSEG, champ KOSTL. Exemples 4100CC_FINANCE_US10010101 | |||
| Clé de devise CurrencyKey | Code de devise des montants enregistrés dans l’écriture comptable. | ||
| Description Cet attribut précise la devise de l’écriture comptable, par exemple USD, EUR ou JPY. Il fournit le contexte nécessaire à l’interprétation des montants financiers associés au document. Bien qu’elle ne constitue pas toujours une dimension d’analyse principale, la devise est essentielle pour interpréter correctement les valeurs monétaires. Elle peut également servir à segmenter l’analyse dans les organisations internationales afin de déterminer si les processus diffèrent pour les écritures en devises étrangères et celles en devise locale. Pourquoi c’est important Fournit le contexte nécessaire à l’ensemble des valeurs monétaires et garantit l’exactitude de l’analyse et de l’interprétation financières. Où les obtenir Située dans la table d’en-tête des documents BKPF, champ WAERS. Exemples USDEURGBPJPY | |||
| Délai d’approbation ApprovalTime | Temps écoulé entre la soumission d’une écriture comptable pour approbation et son approbation ou son rejet. | ||
| Description Cette métrique mesure la durée du sous-processus d’approbation, qui contribue souvent de manière importante au temps de cycle global. Elle correspond à la différence entre l’activité « Journal Entry Submitted » et l’activité « Journal Entry Approved » ou « Journal Entry Rejected » correspondante. Approval Time est la métrique principale du Dashboard « Journal Entry Approval Performance » et du KPI « Average Journal Entry Approval Time ». L’analyse de cette durée permet d’identifier les goulots d’étranglement du flux de travail d’approbation, de mesurer la performance des approbateurs et d’étayer des changements de processus, comme l’ajustement des seuils d’approbation. Pourquoi c’est important Cette métrique quantifie la durée de l’étape d’approbation et aide à repérer puis à traiter les retards du flux de travail d’examen et d’approbation. Où les obtenir Calculé en soustrayant l’horodatage de l’événement « Écriture comptable soumise » de celui de l’événement « Écriture comptable approuvée » ou « Écriture comptable rejetée ». Exemples P1DT2HPT4H15MP3D | |||
| Est en attente IsParked | Indicateur booléen précisant si l’écriture comptable a été enregistrée comme document en attente avant sa comptabilisation. | ||
| Description La mise en attente d’un document permet à un utilisateur d’enregistrer une écriture incomplète sans incidence sur les soldes financiers. Elle peut ensuite être complétée ou vérifiée par un autre utilisateur avant sa comptabilisation. Cet indicateur identifie les écritures ayant suivi une étape de mise en attente. L’analyse de cet attribut permet de comprendre l’utilisation de cette fonctionnalité. Elle peut révéler que la mise en attente sert de contrôle informel et entraîne potentiellement des délais. Elle contribue à l’analyse du délai de traitement de bout en bout, en distinguant les écritures comptabilisées directement de celles qui ont d’abord été mises en attente. Pourquoi c’est important Identifie les écritures ayant utilisé la fonctionnalité de mise en attente, qui peut être une source de délai ou révéler l’existence d’un contrôle informel. Où les obtenir Dérivé du champ de statut du document (BSTAT) dans la table BKPF. La valeur « V » indique un document en attente. Exemples truefalse | |||
| Fait l’objet d’une reprise IsRework | Indicateur booléen précisant si une écriture comptable a suivi une boucle de reprise, par exemple après un rejet suivi d’une correction. | ||
| Description Cet indicateur identifie les cas qui se sont écartés du « parcours nominal » et ont nécessité une mesure corrective. Il est généralement défini sur true lorsqu’une séquence telle que « Écriture comptable rejetée », suivie de « Écriture comptable corrigée », est observée pour une écriture donnée. Cet attribut est essentiel au calcul du KPI « Taux de reprise des écritures comptables » et à l’analyse du Dashboard « Taux de reprise et de rejet ». Il aide à quantifier l’inefficacité du processus et fournit une base pour rechercher les causes profondes des reprises, comme des exigences peu claires ou une documentation insuffisante. Pourquoi c’est important Signale les écritures ayant nécessité une correction, afin de quantifier les reprises et d’en analyser les causes profondes pour améliorer le taux de traitement correct dès la première fois. Où les obtenir Attribut calculé, dérivé de l’analyse de la séquence des activités d’un cas. Une boucle de reprise est identifiée lorsqu’une activité de rejet ou de correction intervient. Exemples truefalse | |||
| Montant total du document TotalDocumentAmount | Valeur totale de l’écriture comptable dans la devise du document. | ||
| Description Cet attribut représente la valeur financière totale de l’écriture comptable. Il est généralement calculé en additionnant les valeurs absolues de tous les postes au débit ou au crédit associés au document. L’analyse du processus selon la valeur financière peut révéler des tendances importantes. Par exemple, les écritures de montant élevé peuvent suivre un parcours d’approbation différent et plus strict. Cet attribut peut servir à filtrer ou à segmenter l’analyse afin de déterminer si les durées de cycle, les taux de rejet ou les retards d’approbation sont corrélés au montant de l’écriture. Pourquoi c’est important Permet d’analyser l’incidence financière, notamment en corrélant les durées de traitement ou les taux de rejet avec la valeur monétaire des écritures comptables. Où les obtenir Il s’agit d’un champ calculé, obtenu par agrégation du champ de montant, WRBTR ou DMBTR, de tous les postes de la table BSEG pour une écriture comptable donnée. Exemples 1500.0025000.75125.50 | |||
| Motif de l’extourne ReversalReason | Code indiquant la raison pour laquelle une écriture comptable a fait l’objet d’une extourne. | ||
| Description Lorsqu’un document est contrepassé, SAP permet à l’utilisateur de préciser un code motif. Ce code fournit des informations structurées sur la raison de la contrepassation, par exemple une date de comptabilisation incorrecte ou une erreur de saisie. Cet attribut constitue une donnée d’entrée essentielle pour le Dashboard « Analyse des contrepassations d’écritures ». En analysant les motifs de contrepassation les plus fréquents, les organisations peuvent identifier les problèmes systémiques de leurs processus ou les lacunes en matière de formation, puis prendre des mesures ciblées afin de prévenir les erreurs futures et de réduire le taux de contrepassation. Pourquoi c’est important Fournit une visibilité directe sur les raisons des contrepassations et permet d’analyser leurs causes profondes afin de réduire les erreurs futures. Où les obtenir Situé dans la table d’en-tête des documents BKPF, champ STGRD. Exemples 010205 | |||
Record to Report - Activités liées aux écritures comptables
| Activité | Description | ||
|---|---|---|---|
| Écriture comptable approuvée | Cette activité marque l’approbation finale d’une écriture comptable dans un flux de travail et la rend éligible à la comptabilisation. L’événement est enregistré dans le journal du flux de travail lorsque l’étape finale de « libération » ou d’« approbation » est terminée. | ||
| Pourquoi c’est important Il s’agit d’une étape clé qui clôt le processus d’approbation. La durée écoulée jusqu’à cette activité constitue un KPI essentiel de l’efficacité des approbations, tandis que le délai entre cet événement et la comptabilisation mesure le retard post-approbation. Où les obtenir Cet événement est déduit de l’horodatage de fin de l’étape d’approbation finale dans le journal du flux de travail SAP Business. Il s’agit de la dernière action d’approbation avant la comptabilisation du document ou sa mise à disposition pour comptabilisation. Collecte Identifiez la fin de l’étape finale de « libération » ou d’« approbation » dans les journaux du flux de travail. Type d’événement inferred | |||
| Écriture comptable comptabilisée | Il s’agit de l’activité centrale au cours de laquelle l’écriture comptable est officiellement enregistrée dans le grand livre et a une incidence sur les états financiers. Cet événement est capturé explicitement lorsque le statut du document est défini sur « posted » et qu’une date de comptabilisation est attribuée. | ||
| Pourquoi c’est important Il s’agit de l’étape la plus importante, qui confirme le traitement réussi d’une écriture comptable. La durée du cycle de bout en bout est souvent mesurée jusqu’à ce point, qui constitue également un événement clé pour l’analyse de la clôture financière. Où les obtenir Identifié lorsqu’un document de la table BKPF possède une date de comptabilisation, BKPF-BUDAT. Pour les documents mis en attente, cela correspond au moment où le statut BKPF-BSTAT passe de « V » à une valeur vide. L’horodatage de la comptabilisation correspond à la date de saisie BKPF-CPUDT. Collecte Identifiez le moment où BKPF-BSTAT passe de « V » à une valeur vide ou, pour les comptabilisations directes, utilisez l’événement de création. Type d’événement explicit | |||
| Écriture comptable mise en attente | Cette activité marque la création initiale d’une écriture comptable dans un état préliminaire, avant sa comptabilisation officielle dans le grand livre. Dans SAP, elle est enregistrée explicitement lorsqu’un utilisateur sauvegarde un document au moyen d’une transaction de mise en attente, ce qui définit le statut du document sur « parked ». | ||
| Pourquoi c’est important Il s’agit d’un événement de début essentiel pour les processus comportant une étape d’examen et d’approbation. L’analyse du délai entre la mise en attente et la comptabilisation permet d’identifier les retards survenant avant la comptabilisation et pendant l’approbation. Où les obtenir Cet événement est identifié à partir de la table d’en-tête des documents BKPF. Un document est considéré comme mis en attente lorsqu’il est créé avec le statut BKPF-BSTAT = « V ». L’horodatage de l’événement correspond à la date et à l’heure de création, BKPF-CPUDT et BKPF-CPUTM. Collecte Identifiez la création du document dans BKPF lorsque BKPF-BSTAT vaut « V ». Type d’événement explicit | |||
| Écriture comptable soumise | Cette activité indique qu’une écriture comptable parquée a été finalisée par son créateur et qu’elle est désormais prête à être examinée et approuvée. Elle est généralement enregistrée lors du lancement d’une tâche du flux de travail SAP Business associée au document parqué. | ||
| Pourquoi c’est important Cette étape marque le transfert du créateur vers l’approbateur et déclenche le calcul des KPI de temps de cycle de l’approbation. Elle constitue un jalon important pour mesurer l’efficacité du flux de travail d’approbation. Où les obtenir Cet événement est déduit de l’heure de début de l’instance du flux de travail d’approbation liée à l’objet du document financier. Il faut analyser des tables de journaux du flux de travail telles que SWW_WI2OBJ afin de retrouver le flux de travail lancé pour le code société, le numéro de document et l’exercice concernés. Collecte Identifiez l’événement de début du flux de travail pour l’objet du document parqué. Type d’événement inferred | |||
| Processus d’extourne d’écriture comptable traité | Cette activité marque l’extourne d’une écriture comptable précédemment comptabilisée. Une extourne est un nouveau document comptable qui annule l’écriture initiale. | ||
| Pourquoi c’est important Il s’agit d’un événement essentiel pour mesurer la qualité des données et l’exactitude du processus. Un taux élevé d’extournes révèle des problèmes systémiques lors de la saisie initiale ou des étapes d’approbation, chaque extourne représentant une reprise. Où les obtenir Cet événement est identifié dans l’en-tête du document d’origine, dans la table BKPF. Lorsqu’un document fait l’objet d’une extourne, SAP renseigne le numéro du document d’extourne, BKPF-STBLG, et le motif d’extourne, BKPF-STGRD. L’horodatage de l’événement correspond à la date de comptabilisation du nouveau document d’extourne. Collecte Identifiez le moment où BKPF-STBLG est renseigné dans le document d’origine. L’horodatage correspond à la date de comptabilisation du document d’extourne. Type d’événement explicit | |||
| Comptabilisation intersociétés identifiée | Activité calculée qui signale qu’une écriture comptable concerne plusieurs codes société. Cette information est déterminée par l’analyse des postes d’un même document financier. | ||
| Pourquoi c’est important Les transactions intersociétés peuvent nécessiter des traitements et des approbations plus complexes. Leur identification permet d’analyser séparément leurs durées de cycle et leurs parcours afin de détecter des goulots d’étranglement spécifiques. Où les obtenir Calculée en examinant la table des postes BSEG pour un numéro de document donné, BELNR. Si les postes contiennent plusieurs codes société distincts, BSEG-BUKRS, l’écriture correspond à une comptabilisation intersociétés. Collecte Vérifiez si plusieurs valeurs distinctes de BSEG-BUKRS existent pour un même BKPF-BELNR. Type d’événement calculated | |||
| Documentation jointe | Cette activité représente l’ajout par un utilisateur de documents justificatifs, tels que des factures ou des feuilles de calcul, à l’écriture comptable. Cet événement n’est pas enregistré explicitement comme un événement comptable standard. Il est généralement déduit de la création de pièces jointes associées à l’objet document comptable. | ||
| Pourquoi c’est important Le suivi de cette activité permet de vérifier le respect des politiques exigeant la présence de documents justificatifs. Les retards dans l’ajout des documents peuvent être à l’origine de cycles d’approbation prolongés. Où les obtenir Il est difficile de capturer cette activité de manière fiable sous la forme d’un événement horodaté. Elle peut éventuellement être déduite de l’analyse des tables de pièces jointes Generic Object Services (GOS), telles que SOOD, et de l’association de l’horodatage de création de la pièce jointe à la clé d’objet de l’écriture comptable. Collecte Déduire l’événement de l’horodatage de création des objets associés dans les tables GOS, par exemple SOOD. Type d’événement inferred | |||
| Écriture comptable corrigée | Cette activité indique que le créateur initial a modifié une écriture comptable mise en attente après son renvoi pour correction. Elle est déduite de la détection de modifications apportées au document après un événement « Changes Requested ». | ||
| Pourquoi c’est important Le suivi des corrections permet de quantifier l’effort consacré aux reprises. Le délai entre la demande de modification et la correction met en évidence les retards dans la résolution des problèmes liés aux écritures soumises. Où les obtenir Cet événement est déduit de l’analyse des journaux de documents de modification, dans les tables CDHDR et CDPOS, pour le document parqué. Une modification enregistrée après un rejet dans le flux de travail indique qu’une correction a été effectuée. L’horodatage provient de la table CDHDR. Collecte Identifiez l’entrée du journal de modifications dans CDHDR/CDPOS après un événement de rejet. Type d’événement inferred | |||
| Écriture comptable créée | Représente la création d’une écriture comptable comptabilisée directement, sans étape préalable de mise en attente. Cette activité est enregistrée lorsqu’un document est créé dans SAP au moyen d’une transaction de comptabilisation directe. | ||
| Pourquoi c’est important Cette activité constitue un point de départ alternatif pour les processus d’écritures comptables simples qui ne nécessitent pas de flux de travail d’approbation. Elle permet de distinguer les comptabilisations directes simples des écritures parquées plus complexes. Où les obtenir Cet événement correspond à la création d’un document dans la table BKPF lorsque le statut du document BKPF-BSTAT est vide, ce qui indique une comptabilisation. L’horodatage de l’événement correspond à la date de création, BKPF-CPUDT. Pour ces documents, les événements « Created » et « Posted » se produisent simultanément. Collecte Identifiez la création du document dans BKPF lorsque BKPF-BSTAT est vide. Type d’événement explicit | |||
| Écriture comptable mise en attente supprimée | Représente la suppression d’une écriture comptable mise en attente qui n’a jamais été comptabilisée. Cela peut se produire après un rejet ou lorsque l’écriture a été créée par erreur. | ||
| Pourquoi c’est important Cette activité marque une fin infructueuse du processus. L’analyse des raisons pour lesquelles les documents mis en attente sont supprimés peut révéler des problèmes tels que des doublons ou une mauvaise compréhension du processus. Où les obtenir Cet événement est capturé lorsque le statut d’un document mis en attente dans la table BKPF est modifié. Le champ de statut BKPF-BSTAT est mis à jour avec la valeur « Z », qui signifie « Parked document deleted ». L’horodatage de la modification se trouve dans les journaux de modification des documents, CDHDR. Collecte Identifiez le moment où BKPF-BSTAT est mis à jour avec la valeur « Z ». Type d’événement explicit | |||
| Écriture comptable rejetée | Cette activité indique le rejet final d’une écriture comptable, qui ne sera ensuite pas comptabilisée. Il s’agit généralement d’un statut terminal du flux de travail d’approbation, qui entraîne à terme la suppression du document parqué. | ||
| Pourquoi c’est important Le suivi des rejets est essentiel à la gestion de la qualité. L’analyse des motifs et de la fréquence des rejets permet d’améliorer le taux d’écritures comptables correctes dès la première tentative. Où les obtenir Il s’agit d’un résultat enregistré dans le journal du flux de travail SAP Business, correspondant à une décision utilisateur finale de « rejet » qui met fin au processus. Le document parqué peut ensuite être supprimé. Collecte Identifiez le statut terminal « rejeté » dans le journal du flux de travail du document. Type d’événement inferred | |||
| Modifications demandées sur l’écriture comptable | Cette étape représente le moment où un approbateur a examiné l’écriture comptable et l’a renvoyée à son créateur pour correction. L’événement est enregistré dans les journaux du flux de travail, qui indiquent une décision utilisateur de « rejet » ou de « renvoi ». | ||
| Pourquoi c’est important Cette activité est essentielle pour identifier les boucles de correction, qui constituent une source majeure d’inefficacité et d’écarts dans le processus. Une fréquence élevée de cet événement indique des problèmes de qualité des écritures ou des exigences peu claires. Où les obtenir Cet événement est déduit de l’horodatage d’une étape de décision utilisateur précise dans le journal du flux de travail SAP Business, correspondant à une action de « rejet » ou de « renvoi pour correction ». Collecte Identifiez l’horodatage de la décision de « rejet » ou de « reprise » dans les journaux du flux de travail. Type d’événement inferred | |||
| Poste d’écriture comptable lettré | Cette activité représente le rapprochement d’un poste d’un compte de grand livre géré en postes ouverts, tel qu’un compte d’attente bancaire. Elle se produit lorsqu’un poste est rapproché avec un autre, ce qui le solde. | ||
| Pourquoi c’est important Pour des processus tels que le rapprochement bancaire, le délai de lettrage des postes constitue un KPI essentiel. Cette activité permet d’analyser l’efficacité des procédures de rapprochement et de clôture de fin de mois. Où les obtenir Cet événement est capturé à partir de la table des postes BSEG. Lorsqu’un poste est lettré, les champs de date de lettrage, BSEG-AUGDT, et de document de lettrage, BSEG-AUGBL, sont renseignés. L’horodatage de l’événement correspond à la date de lettrage. Collecte Identifiez le moment où la date de lettrage, BSEG-AUGDT, est renseignée pour un poste. Type d’événement explicit | |||
| Saisie manuelle identifiée | Cette activité indique si une écriture comptable a été créée au moyen d’une transaction en ligne manuelle, plutôt que par une interface automatisée ou un traitement par lots. Il ne s’agit pas d’une action utilisateur, mais d’un attribut calculé de l’écriture, dérivé des données du système. | ||
| Pourquoi c’est important La distinction entre les écritures manuelles et automatisées est essentielle pour cibler les améliorations du processus. Les processus manuels sont souvent prioritaires dans les initiatives de standardisation et d’automatisation. Où les obtenir Cette information est calculée à partir des champs de la table d’en-tête des documents BKPF. Des codes de transaction, tels que « FB01 », « FB50 » ou « FV50 » dans BKPF-TCODE, indiquent une saisie manuelle, tandis que d’autres codes T ou certains noms de saisie par lots dans BKPF-AWKEY suggèrent une automatisation. Collecte Dériver l’information de BKPF-TCODE ou d’autres indicateurs du système source présents dans l’en-tête du document. Type d’événement calculated | |||
Guides d’extraction
Étapes
- Créer le programme ABAP : dans le système SAP, accédez au code de transaction SE38 (éditeur ABAP). Saisissez un nom pour le nouveau programme, par exemple Z_PM_JE_EXTRACTION, puis cliquez sur Create. Indiquez un titre approprié et définissez le type de programme sur « Executable Program ».
- Définir l’écran de sélection : dans le code source du programme, définissez l’écran de sélection. Les utilisateurs pourront ainsi préciser des paramètres tels qu’une plage de dates de création des documents, des sociétés et des types de documents afin de limiter le volume de données extrait.
- Déclarer les structures de données : définissez une structure de table interne destinée à contenir les données finales du journal d’événements. Elle doit inclure tous les champs requis : JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, ainsi que des attributs recommandés comme User, CompanyCode et PostingDate.
- Implémenter la logique de sélection des données : écrivez les requêtes SQL ABAP principales pour extraire les données correspondant aux 14 activités requises. Il s’agit notamment de sélectionner des données dans les tables principales telles que BKPF (en-tête) et BSEG (poste), les tables des journaux de modifications CDHDR et CDPOS, les tables de flux de travail telles que SWWLOGHIST, ainsi que les tables de lettrage telles que BSAS et BSAK.
- Extraire les documents préenregistrés et comptabilisés : pour les événements « Journal Entry Parked », sélectionnez les entrées de BKPF dont le statut du document (BSTAT) est « V ». Pour les événements « Journal Entry Created » et « Journal Entry Posted », sélectionnez les entrées de BKPF dont le statut est vide, ce qui indique un document normal et comptabilisé.
- Extraire les événements de modification et de suppression : interrogez les tables de documents de modification CDHDR et CDPOS pour la classe d’objet « BELEG ». Filtrez la clé du document afin de trouver les modifications correspondant aux activités « Journal Entry Corrected » ou « Parked Journal Entry Deleted ».
- Extraire les événements de flux de travail : pour capturer des activités telles que « Journal Entry Submitted », « Approved », « Rejected » et « Changes Requested », interrogez les tables de flux de travail. Utilisez SWW_WI2OBJ pour relier le document comptable à une instance de flux de travail, puis lisez SWWLOGHIST afin d’identifier les décisions des utilisateurs ou les changements de statut.
- Identifier les événements calculés : pour « Manual Entry Identified », vérifiez le code de transaction (BKPF-TCODE) par rapport à une liste de codes de saisie manuelle connus. Pour « Cross-Company Posting Identified », analysez les postes BSEG d’un document afin de déterminer si plusieurs sociétés sont concernées.
- Consolider et transformer les données : à mesure que les données de chaque activité sont sélectionnées, transformez-les selon la structure finale du journal d’événements. Concaténez Company Code, Document Number et Fiscal Year pour créer JournalEntryId. Convertissez les dates et heures SAP en un horodatage EventTime unique. Ajoutez les résultats de chaque requête à la table interne finale.
- Implémenter l’export du fichier : utilisez les instructions ABAP de gestion des fichiers, telles que OPEN DATASET, LOOP AT, TRANSFER et CLOSE DATASET, pour écrire la table interne consolidée dans un fichier CSV ou texte sur le répertoire du serveur d’applications SAP, consultable via la transaction AL11.
- Planifier l’exécution en tâche de fond : accédez à la transaction SM36 (définition d’une tâche de fond). Créez une nouvelle tâche, définissez une étape qui exécute votre programme ABAP et planifiez son exécution, par exemple chaque nuit ou chaque semaine en dehors des heures de pointe, afin d’automatiser l’extraction.
- Récupérer et formater le fichier : utilisez la transaction CG3Y ou demandez à votre administrateur système de télécharger le fichier généré depuis le serveur d’applications vers votre poste local. Vérifiez que son encodage et son format conviennent à l’importation dans votre outil de Process Mining.
Configuration
- Plage de dates : il est essentiel de définir une plage de dates pour maîtriser les performances. Utilisez la date de création du document (BKPF-CPUDT) comme filtre principal. Pour une première analyse, une période de 3 à 6 mois est recommandée. Pour les tests, utilisez une période de quelques jours dont vous savez qu’elle contient des données.
- Filtre par société : filtrez toujours par société (BKPF-BUKRS). Extraire simultanément les données de toutes les sociétés peut mobiliser énormément de ressources. Commencez par une seule société ou par un petit groupe de sociétés pertinentes.
- Filtre par type de document : utilisez le filtre de type de document (BKPF-BLART) pour limiter le périmètre à certains types d’écritures, par exemple « SA » pour les documents de grand livre, si vous n’avez pas besoin d’analyser tous les types de documents.
- Identifiants des tâches de flux de travail : la logique d’extraction des événements de flux de travail dépend des identifiants de tâches utilisés dans votre système pour l’approbation, le rejet et la soumission. Ces identifiants doivent être configurés dans le code source du programme selon les définitions de flux de travail de votre entreprise.
- Considérations relatives aux performances : le programme joint plusieurs tables volumineuses, notamment CDPOS et les tables d’historique des flux de travail. Une exécution pendant les heures de pointe peut affecter les performances du système. Planifiez toujours l’exécution en tâche de fond, en dehors des heures de pointe. Envisagez de créer des index secondaires dans la base de données si les problèmes de performance se répètent.
- Prérequis : cette méthode nécessite un utilisateur disposant des autorisations de développement ABAP (pour SE38), ainsi que des droits permettant de créer et de gérer des tâches de fond (pour SM36). L’utilisateur ou la tâche doit également disposer d’un accès en lecture à toutes les tables financières, de flux de travail et système pertinentes (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST, etc.).
a Exemple de requête abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Étapes
- Établir la connexion à la base de données : obtenez des identifiants en lecture seule pour la base de données SAP ECC. Utilisez un client SQL standard, tel que DBeaver, SAP HANA Studio ou SQL Server Management Studio, pour vous connecter à la base de données.
- Préparer la requête SQL : copiez la requête SQL complète fournie dans la section « query » de ce document dans votre client SQL.
- Définir les paramètres d’extraction : avant l’exécution, configurez les espaces réservés de la requête. Remplacez « [START_DATE] » et « [END_DATE] » par la période souhaitée au format « YYYYMMDD ». Remplacez « [COMPANY_CODE_1] » et « [COMPANY_CODE_2] » par les codes société SAP à analyser.
- Définir le système source : dans l’instruction
SELECTprincipale, remplacez l’espace réservé « [Your SAP System ID] » par l’identifiant réel du système SAP (SID) afin d’identifier correctement la source des données. - Exécuter la requête : exécutez la requête SQL configurée sur la base de données SAP. La durée d’exécution varie selon la période et la taille des tables de votre base de données.
- Vérifier les premiers résultats : une fois la requête terminée, examinez brièvement les lignes renvoyées pour vérifier que les données sont renseignées comme prévu. Vérifiez la présence de différentes activités et assurez-vous que les champs clés tels que
JournalEntryIdetEventTimene sont pas vides. - Gérer les horodatages : la requête concatène les champs de date et d’heure dans une chaîne
YYYYMMDDHHMMSS. Vérifiez que votre traitement ultérieur ou votre système cible peut analyser ce format, ou adaptez la fonction SQLCONCATau format ISO 8601, par exempleYYYY-MM-DDTHH:MI:SS, si votre base de données le permet. - Exporter les données : exportez l’ensemble des résultats depuis votre client SQL vers un fichier CSV. Utilisez l’encodage UTF-8 afin d’éviter les problèmes liés aux caractères spéciaux.
- Préparer l’importation : avant d’importer le fichier dans un outil de Process Mining, vérifiez que les en-têtes de colonnes correspondent au schéma de données requis.
JournalEntryId,ActivityNameetEventTimesont essentiels. Ajoutez la colonneLastDataUpdateet renseignez-la avec l’horodatage de l’extraction. - Validation finale : suivez les étapes indiquées dans la section « validationSteps » afin de vérifier que les données extraites sont complètes et exactes avant de commencer l’analyse.
Configuration
- Autorisations de la base de données : l’utilisateur de la base de données doit disposer d’un accès en lecture aux tables SAP suivantes : BKPF, BSEG, CDHDR, CDPOS, T001 et V_USERNAME. Pour les activités liées au Workflow, l’accès à SWW_WI2OBJ et SWWLOGHIST est également nécessaire. Ce niveau d’accès est généralement accordé uniquement à des équipes techniques spécialisées.
- Filtrage par période : il est essentiel de filtrer les données selon une période précise afin de préserver les performances des requêtes. La requête fournie utilise des espaces réservés pour les dates de début et de fin, appliquées à la date de création du document (
BKPF.CPUDT). Une période de 3 à 6 mois est recommandée pour une première analyse. - Filtrage par entité : pour maîtriser le volume de données et cibler l’analyse, filtrez toujours par code société (
BKPF.BUKRS). Vous pouvez également filtrer par type de document (BKPF.BLART) afin de ne conserver que les types d’écritures comptables pertinents, par exemple « SA » pour les documents du grand livre, et d’exclure les documents opérationnels tels que les factures ou les paiements lorsqu’ils ne sont pas dans le périmètre. - Performances : les requêtes directes sur des tables principales telles que BSEG et CDPOS peuvent mobiliser beaucoup de ressources. Il est vivement recommandé d’exécuter cette extraction en dehors des heures de pointe afin de ne pas affecter les performances du système pour les utilisateurs finaux. Évitez d’extraire plus d’une année de données en une seule exécution.
- Identifiants des tâches de Workflow : la requête contient des espaces réservés tels que « [WF_TASK_ID_SUBMIT] » et « [WF_TASK_ID_APPROVE] ». Ils doivent être remplacés par les identifiants réels des tâches définis dans la configuration du Workflow des écritures comptables de votre système. Vous pouvez les identifier avec l’aide d’un spécialiste SAP Workflow ou en analysant la définition technique du Workflow dans la transaction PFTC.
a Exemple de requête sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Étapes
- Établissez la connexion SAP : Dans votre outil ETL tiers, configurez une nouvelle connexion source vers votre système SAP ECC. Vous aurez généralement besoin des informations du serveur d’application, du mandant, du numéro de système et d’un utilisateur SAP dédié disposant des autorisations RFC nécessaires.
- Définissez les sources de données : Dans votre projet d’extraction, ajoutez les tables SAP requises comme sources de données. Les principales tables sont BKPF (en-tête du document comptable), BSEG (segment du document comptable), VBSEGK (en-tête du document préenregistré), CDHDR (en-tête du document de modification), CDPOS (postes du document de modification), SWW_WI2OBJ (liens entre flux de travail et objets), SWWLOGHIST (journal du flux de travail) et SRGBTBREL (relations des pièces jointes GOS).
- Extrayez les événements de base (créé et préenregistré) : Créez le premier flux de données pour extraire les événements initiaux. Pour « Journal Entry Parked », utilisez VBSEGK comme source. Pour « Journal Entry Created », utilisez BKPF, en filtrant les documents qui ne sont pas des extournes et qui n’ont pas été initialement préenregistrés. Vous pouvez effectuer cette opération au moyen d’une anti-jointure avec VBSEGK.
- Extrayez les événements des flux de travail : Créez un flux de données qui joint BKPF à SWW_WI2OBJ à l’aide de la clé d’objet, composée du code société, du numéro de document et de l’exercice, afin de trouver l’identifiant de l’instance du flux de travail. Joignez ce résultat à SWWLOGHIST pour extraire les événements tels que « Submitted », « Approved », « Rejected » et « Changes Requested », selon les résultats des tâches du flux de travail et les décisions des utilisateurs enregistrées dans le journal.
- Extrayez les événements de modification et de suppression : Utilisez les tables CDHDR et CDPOS pour identifier les modifications. Pour « Journal Entry Corrected », filtrez les modifications apportées aux documents préenregistrés, dont la classe d’objet est « FIPP ». Pour « Parked Journal Entry Deleted », recherchez les marqueurs de suppression dans les journaux de modification des documents préenregistrés.
- Extrayez les événements liés aux pièces jointes : Pour enregistrer « Documentation Attached », joignez BKPF à SRGBTBREL lorsque le type d’objet est « BKPF » et que la relation correspond à « [Your attachment relationship type] ». La date de création du lien sert d’heure de l’événement.
- Extrayez les événements de lettrage et d’extourne : Pour « Journal Entry Line Item Cleared », interrogez la table BSEG lorsque le champ du document de lettrage (AUGBL) est renseigné. L’heure de l’événement correspond à la date de comptabilisation du document de lettrage (AUGDT). Pour « Journal Entry Reversal Processed », interrogez BKPF afin d’identifier les documents d’extourne, caractérisés par une valeur dans le champ du document extourné (STBLG).
- Déduisez les événements calculés : Créez des blocs de logique distincts pour les événements calculés. Pour « Manual Entry Identified », filtrez BKPF à partir d’une liste de codes de transaction manuels, par exemple FB01, FB50 et F-02. Pour « Cross-Company Posting Identified », regroupez la table BSEG par identifiant de document et identifiez les documents associés à plusieurs codes société distincts.
- Regroupez tous les flux d’événements : Utilisez une transformation UNION dans votre outil ETL pour fusionner les résultats de tous les flux d’événements individuels, tels que Created, Parked et Approved, dans une table unique de journal d’événements. Vérifiez que les noms et les types de données des colonnes sont cohérents dans tous les flux.
- Associez les données au schéma final : Associez les données regroupées à la structure requise du journal d’événements en créant
JournalEntryId,ActivityName,EventTime,Utilisateuret les autres attributs requis ou recommandés. Ajoutez des colonnes statiques telles queSourceSystemet utilisez l’heure d’exécution du travail ETL pourLastDataUpdate. - Configurez le chargement incrémentiel : Pour les extractions récurrentes, configurez une stratégie de chargement incrémentiel. Utilisez la dernière date de création ou de modification, par exemple BKPF.CPUDT ou CDHDR.UDATE, comme point de contrôle afin de ne récupérer que les enregistrements nouveaux ou mis à jour depuis la dernière exécution.
- Exportez les données vers ProcessMind : Planifiez le travail d’extraction et configurez l’étape de sortie finale afin d’enregistrer le journal d’événements au format CSV ou Parquet dans un emplacement accessible par ProcessMind pour l’importation.
Configuration
- Prérequis : un outil ETL tiers sous licence, par exemple Theobald Xtract Universal, Informatica ou Talend, doté d’un connecteur SAP dédié. Vous devez également disposer d’un compte utilisateur SAP avec un accès RFC et des autorisations de lecture des tables financières, par exemple S_TABU_DIS pour les groupes de tables F_00 et F_WF, ainsi que des données de flux de travail et des journaux de modifications.
- Paramètres de connexion : vous aurez besoin de l’adresse IP ou du nom d’hôte du serveur d’applications SAP, du numéro du système et de l’identifiant client. Utilisez une gestion sécurisée des identifiants pour le nom d’utilisateur et le mot de passe SAP.
- Filtres principaux : appliquez toujours les filtres Société (BKPF.BUKRS) et Exercice (BKPF.GJAHR) à la source afin de limiter le volume de données. Il est fortement recommandé de filtrer la date de création du document (BKPF.CPUDT) afin de définir une période d’extraction précise, par exemple les six derniers mois.
- Sélection de la plage de dates : pour le chargement initial, sélectionnez une période représentative de 3 à 6 mois. Pour les chargements différentiels suivants, utilisez un point de reprise sur un champ d’horodatage tel que
CPUDTafin de récupérer uniquement les nouveaux enregistrements. - Considérations relatives aux performances : les jointures sur BSEG, CDPOS et les tables de flux de travail peuvent être très lentes. Vérifiez que votre outil ETL pousse les filtres vers la source SAP lorsque cela est possible. Extrayez les données par lots ou paquets de plus petite taille si l’outil le permet, en particulier pour les chargements historiques volumineux.
- Personnalisation des flux de travail : la logique d’identification des activités de flux de travail telles que « Approved » ou « Rejected » dépend largement de vos modèles de flux de travail. Vous devrez identifier les identifiants corrects des tâches de flux de travail et les clés de décision des utilisateurs dans votre système afin de les utiliser dans les filtres.
a Exemple de requête sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 Prêt à commencer ?
Utilisez ce modèle de données pour commencer rapidement votre démarche de Process Mining appliquée au processus Record to Report - Journal Entry. Obtenez des analyses plus détaillées et améliorez l’efficacité de vos opérations financières.
Optimisez dès maintenant votre processus Record to Report, écritures comptables
Réduisez de 30 % le délai du cycle des écritures comptables et garantissez une information financière irréprochable.
Aucune carte bancaire n’est requise. Commencez à améliorer vos processus dès aujourd’hui.