Votre modèle de données Record to Report - Écritures de journal
Votre modèle de données Record to Report - Écritures de journal
- Attributs recommandés pour une analyse approfondie
- Activités clés d'écritures comptables à suivre
- Guide pratique d'extraction de données pour SAP ECC
Attributs Record to Report - Écritures comptables
| Nom | Description | ||
|---|---|---|---|
| Heure de l'événement EventTime | L'horodatage indiquant quand une activité ou un événement spécifique s'est produit pour l'écriture comptable. | ||
| Description L'heure de l'événement fournit la date et l'heure exactes pour chaque activité du processus d'écritures comptables. Ces données sont cruciales pour le calcul de toutes les métriques basées sur le temps, telles que les temps de cycle, les durées de traitement et les retards entre les étapes. La source de cet horodatage varie selon l'activité ; il peut s'agir de la date/heure de création du document ( En analyse, l'heure de l'événement est utilisée pour ordonner les événements chronologiquement, formant la base de la carte de processus. Elle est essentielle pour le calcul de tous les KPI liés au temps, tels que le temps de cycle moyen des écritures comptables, le temps d'approbation moyen et le temps entre l'approbation et la comptabilisation. Pourquoi c'est important Cet horodatage est la base de toutes les analyses temporelles, permettant le calcul des temps de cycle, des durées et des goulots d'étranglement. Où obtenir Provenant de divers champs selon l'activité, principalement l'horodatage de création (CPUDT, CPUTM) de BKPF ou les horodatages de documents de modification (UDATE, UTIME) de CDHDR. Exemples 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| ID d'écriture comptable JournalEntryId | L'identifiant unique pour un document comptable financier, combinant le code société, le numéro de document et l'année fiscale. | ||
| Description L'ID d'écriture comptable (Journal Entry ID) est l'identifiant de cas principal pour suivre le cycle de vie d'une écriture comptable. C'est une clé composite, généralement formée en concaténant le code société (BUKRS), le numéro de document (BELNR) et l'année fiscale (GJAHR) pour assurer l'unicité à travers l'ensemble du système SAP. Dans l'analyse des processus, cet ID relie toutes les activités associées, telles que la création, le pré-enregistrement, la soumission, l'approbation, le rejet et la comptabilisation. En traçant cet identifiant, nous pouvons construire le parcours de bout en bout de chaque écriture comptable, mesurer les temps de cycle et identifier les déviations de processus ou les goulots d'étranglement pour des écritures spécifiques. Pourquoi c'est important C'est la clé essentielle pour suivre une écriture comptable de sa création à sa comptabilisation finale, permettant une analyse de processus de bout en bout et une comparaison des variantes. Où obtenir C'est un attribut dérivé, généralement une concaténation de champs de la table BKPF : Code société (BUKRS), Numéro de document (BELNR) et Année fiscale (GJAHR). Exemples 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Nom de l'activité ActivityName | Le nom de l'activité commerciale ou de l'événement qui s'est produit à un moment précis du processus d'écritures comptables. | ||
| Description Le Nom de l'Activité décrit une étape spécifique du cycle de vie de l'écriture comptable, telle que 'Écriture comptable créée', 'Écriture comptable approuvée' ou 'Écriture comptable comptabilisée'. Cet attribut est généralement dérivé de multiples sources dans SAP, y compris les codes de transaction (TCODE), les journaux de modifications de documents (tables CDHDR et CDPOS) et les champs de statut de document. L'analyse des activités est le cœur du process mining. Elle permet la visualisation de la cartographie des processus, le calcul des temps de transition entre les étapes et l'identification des boucles de retravail (par exemple, 'Écriture comptable rejetée' suivie de 'Écriture comptable corrigée'). Ces données sont fondamentales pour les dashboards liés aux temps de cycle, aux taux de retravail et aux variantes de processus. Pourquoi c'est important Il définit les étapes de la cartographie des processus, permettant de visualiser, d'analyser et d'optimiser le workflow des écritures comptables. Où obtenir Dérivé de diverses sources, y compris les codes de transaction dans BKPF (TCODE), le statut du document, et les journaux de workflow dans des tables comme SWW_WI2OBJ, ou les documents de modification dans CDHDR et CDPOS. Exemples Écriture de journal crééeÉcriture comptable approuvéeÉcriture comptable rejetéeÉcriture comptable comptabilisée | |||
| Dernière mise à jour des données LastDataUpdate | L'horodatage indiquant la dernière extraction ou le dernier rafraîchissement des données depuis le système source. | ||
| Description Cet attribut enregistre la date et l'heure de la dernière extraction de données de SAP ECC. C'est un champ de métadonnées essentiel pour comprendre la fraîcheur et l'actualité des données analysées. Dans tout dashboard ou analyse de process mining, connaître l'heure de la dernière mise à jour est crucial pour que les utilisateurs fassent confiance aux données et prennent des décisions éclairées. Cela aide à répondre à la question : "Ces informations sont-elles à jour ?". Pourquoi c'est important Informe les utilisateurs de la fraîcheur des données, garantissant qu'ils comprennent la période d'analyse et peuvent faire confiance aux résultats. Où obtenir C'est un champ de métadonnées généré et stocké par l'outil d'extraction de 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 | Le `système` d'où les `données` du `processus` ont été extraites. | ||
| Description Cet attribut identifie l'origine des données, qui dans ce cas est l'instance spécifique de SAP ECC. C'est typiquement une valeur statique ajoutée pendant le processus d'extraction de données. Bien que simple, cet attribut est important dans les environnements avec plusieurs ERP ou sources de données. Il garantit que la lignée des données est claire et permet de filtrer ou de segmenter l'analyse par système d'origine. Pourquoi c'est important Fournit une lignée de données claire et est essentiel pour le suivi de la qualité des données, en particulier dans les environnements avec plusieurs systèmes sources. Où obtenir C'est typiquement une valeur statique ajoutée pendant le processus de transformation des données, identifiant l'instance spécifique de SAP ECC (par exemple, 'ECC_PROD_100'). Exemples SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Code de transaction TransactionCode | Le code de transaction SAP utilisé pour créer ou traiter l'écriture comptable. | ||
| Description Le code de transaction (T-Code) est un identifiant unique pour une fonction ou un programme spécifique dans SAP. Pour les écritures comptables, il indique comment l'écriture a été créée, par exemple, manuellement (FB01, F-02), via le pré-enregistrement (FV50), ou par une interface automatisée. Cet attribut est inestimable pour le dashboard 'Optimisation des activités manuelles'. En analysant le T-Code, nous pouvons distinguer les activités manuelles des activités automatisées, identifier les processus manuels les plus chronophages et repérer les opportunités d'automatisation pour réduire l'effort manuel et améliorer l'efficacité. Pourquoi c'est important Aide à différencier les processus manuels et automatisés, identifiant les opportunités d'automatisation et de standardisation des processus. Où obtenir Situé dans la table d'en-tête de document BKPF, champ TCODE. Exemples FB01F-02FV50FBD1 | |||
| Code société CompanyCode | L'unité organisationnelle représentant une entité juridique indépendante pour laquelle des états financiers sont préparés. | ||
| Description Le code société (Company Code) est une unité organisationnelle fondamentale dans SAP Financials. Il représente une entreprise juridiquement indépendante et est un champ clé dans 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 les performances des processus, les taux de conformité et les résultats des KPI à travers les différentes parties de l'entreprise. Par exemple, il peut aider à identifier si les retards d'approbation ou les taux d'annulation élevés sont spécifiques à certains codes société. Pourquoi c'est important Permet de filtrer et de comparer la performance des processus entre différentes entités légales ou unités commerciales au sein de l'organisation. Où obtenir Situé dans la table d'en-tête de document BKPF, champ BUKRS. Exemples 10002000US01DE01 | |||
| Date de comptabilisation PostingDate | La date à laquelle la transaction est enregistrée dans le grand livre général, affectant la période financière. | ||
| Description La date de comptabilisation (Posting Date) détermine la période fiscale durant laquelle l'écriture comptable est prise en compte. C'est un champ de date critique du point de vue financier et de la conformité, car il doit s'aligner avec les calendriers de clôture des périodes comptables et les réglementations. Dans le process mining, cette date est utilisée pour surveiller la conformité. Le dashboard 'Suivi de l'adhésion à la conformité' et le KPI 'Taux de conformité' utilisent cet attribut pour vérifier si les écritures sont comptabilisées dans la bonne période. Il peut également être utilisé pour analyser les tendances des volumes d'écritures comptables au fil du temps. Pourquoi c'est important Crucial pour les rapports financiers et l'analyse de conformité, garantissant que les écritures sont comptabilisées dans la bonne période comptable. Où obtenir Situé dans la table d'en-tête de document BKPF, champ BUDAT. Exemples 2023-10-312023-11-302024-01-15 | |||
| Est annulée IsReversed | Un indicateur booléen signalant si l'écriture comptable a été annulée. | ||
| Description Cet indicateur identifie les écritures comptables qui ont été ultérieurement annulées par un autre document comptable. Dans SAP, un document annulé est lié au document d'annulation, fournissant une piste d'audit claire. Cet attribut est fondamental pour le dashboard 'Analyse des annulations d'écritures comptables' et le KPI 'Taux d'annulation des écritures comptables'. Il permet d'isoler les écritures annulées pour enquêter sur les causes profondes, telles que les erreurs de saisie de données ou les traitements comptables incorrects, dans le but de réduire la fréquence des annulations. Pourquoi c'est important Prend directement en charge l'analyse des annulations en signalant les écritures qui ont été annulées ultérieurement, aidant à identifier les causes profondes des erreurs et à améliorer l'intégrité des données. Où obtenir Dérivé du champ Numéro de document d'annulation ( Exemples truefaux | |||
| Type de document DocumentType | Une classification pour les documents comptables qui contrôle la manière dont ils sont traités et stockés. | ||
| Description Le type de document (Document Type) distingue différents types de transactions commerciales, telles qu'une écriture de grand livre général (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. C'est un attribut critique pour l'analyse car il permet de segmenter le processus par la nature de la transaction. Le dashboard 'Débit des écritures comptables par type' et le KPI 'Temps de cycle moyen par type d'écriture comptable' dépendent directement de ce champ. Il aide à découvrir si certains types d'écritures sont plus sujets aux retards, au retravail ou aux annulations. Pourquoi c'est important Permet la segmentation de l'analyse par type de transaction, aidant à identifier si les problèmes de processus sont spécifiques à certains types d'écritures comptables. Où obtenir Situé dans la table d'en-tête de document BKPF, champ BLART. Exemples SAKRREAA | |||
| Utilisateur User | L'ID utilisateur SAP de la personne qui a créé ou modifié l'écriture comptable. | ||
| Description Cet attribut capture le nom d'utilisateur SAP (username) responsable d'une activité donnée, telle que la création, le pré-enregistrement ou la comptabilisation d'un document. Il est directement extrait de l'en-tête du document ou des tables du journal des modifications. L'analyse de l'attribut Utilisateur (User) est essentielle pour comprendre la performance de l'équipe et individuelle. Elle soutient le dashboard 'Productivité des utilisateurs' en suivant les volumes d'activité et les temps de traitement par utilisateur. Elle aide également à identifier qui est impliqué dans les boucles de retravail, les annulations ou les écarts de conformité, permettant des formations ciblées ou des améliorations de processus. Pourquoi c'est important Identifie l'utilisateur responsable de chaque activité, permettant l'analyse des performances des utilisateurs, de la répartition de la charge de travail et des schémas de retravail. Où obtenir Généralement à partir de la table BKPF (champ USNAM pour le créateur) ou de la table CDHDR (champ USERNAME pour le modificateur). Exemples ABROWNCJONESDSMITH | |||
| Centre de coûts CostCenter | Une unité organisationnelle au sein d'un périmètre de contrôle qui représente un lieu où les coûts sont engagés. | ||
| Description Le centre de coûts (Cost Center) est un élément clé de la donnée de base du module Contrôle de gestion (CO), souvent attribué au niveau du poste d'écriture comptable. Il est utilisé pour suivre les coûts d'un département, d'une fonction ou d'un emplacement spécifique. L'inclusion du centre de coûts permet une analyse plus granulaire du processus d'écritures comptables. Elle peut aider à déterminer si certains départements génèrent plus de retravail, ont des temps de cycle plus longs ou sont responsables d'un volume plus élevé d'écritures manuelles. Cela permet une vue départementale de l'efficacité du processus. Pourquoi c'est important Permet l'analyse de la performance des processus par service ou domaine fonctionnel, aidant à identifier les inefficacités localisées. Où obtenir Situé dans la table des postes de document BSEG, champ KOSTL. Exemples 4100CC_FINANCE_US10010101 | |||
| Clé de devise CurrencyKey | Le code de devise pour les montants enregistrés dans l'écriture comptable. | ||
| Description Cet attribut spécifie la devise de l'écriture comptable, telle que USD, EUR ou JPY. Il fournit un contexte pour tous les montants financiers associés au document. Bien que n'étant pas toujours une dimension d'analyse principale, il est crucial pour interpréter correctement les valeurs monétaires. Il peut également être utilisé pour segmenter l'analyse dans les organisations mondiales afin de voir si les processus diffèrent pour les écritures en devises étrangères par rapport aux devises locales. Pourquoi c'est important Fournit le contexte nécessaire pour toutes les valeurs monétaires, garantissant une analyse et une interprétation financières précises. Où obtenir Situé dans la table d'en-tête de document BKPF, champ WAERS. Exemples USDEURGBPJPY | |||
| Est pré-enregistré IsParked | Un indicateur booléen signalant si l'écriture comptable a été enregistrée comme document mis en attente avant d'être comptabilisée. | ||
| Description Le pré-enregistrement d'un document permet à un utilisateur de sauvegarder une écriture comptable incomplète sans qu'elle n'affecte les soldes financiers. Elle peut ensuite être complétée ou révisée par un autre utilisateur avant la comptabilisation. Cet indicateur identifie les écritures qui sont passées par une étape de pré-enregistrement. L'analyse de cet attribut aide à comprendre l'utilisation de la fonction de pré-enregistrement. Elle peut révéler si le pré-enregistrement est utilisé comme une étape de révision informelle, pouvant entraîner des retards. Elle soutient l'analyse du temps de cycle de bout en bout, en distinguant les écritures qui sont comptabilisées directement de celles qui sont d'abord pré-enregistrées. Pourquoi c'est important Identifie les écritures utilisant la fonction de pré-enregistrement, qui peut être une source de délai ou un indicateur d'un processus de révision informel. Où obtenir Dérivé du champ de statut du document ( Exemples truefaux | |||
| Est un retravail IsRework | Un indicateur booléen signalant si une écriture comptable a subi un cycle de reprise, par exemple, ayant été rejetée puis corrigée. | ||
| Description Cet indicateur identifie les cas qui ont dévié du 'chemin optimal' (happy path) et ont nécessité une action corrective. Il est généralement défini sur vrai si une séquence d'activités comme 'Écriture comptable rejetée' suivie de 'Écriture comptable corrigée' est observée pour une écriture comptable donnée. Cet attribut est essentiel pour le calcul du KPI 'Taux de retravail des écritures comptables' et pour l'analyse sur le dashboard 'Taux de retravail et de rejet'. Il aide à quantifier l'étendue de l'inefficacité du processus et fournit une base pour enquêter sur les causes profondes du retravail, telles que des exigences peu claires ou une documentation insuffisante. Pourquoi c'est important Signale les écritures qui ont nécessité une correction, permettant de quantifier les reprises et d'analyser leurs causes profondes pour améliorer les taux de "juste du premier coup". Où obtenir Il s'agit d'un attribut calculé, dérivé de l'analyse de la séquence d'activités pour un cas. Une boucle de retravail est identifiée si une activité de rejet ou de correction se produit. Exemples truefaux | |||
| Montant total du document TotalDocumentAmount | La 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 sommant les valeurs absolues de tous les postes de débit ou de crédit associés au document. L'analyse du processus par valeur financière peut révéler des schémas importants. Par exemple, les écritures de grande valeur peuvent suivre un chemin d'approbation différent, plus rigoureux. Cet attribut peut être utilisé pour filtrer ou segmenter l'analyse afin de voir si les temps de cycle, les taux de rejet ou les retards d'approbation sont corrélés avec le montant de l'écriture. Pourquoi c'est important Permet une analyse d'impact financier, comme la corrélation des temps de traitement ou des taux de rejet avec la valeur monétaire des écritures comptables. Où obtenir C'est un champ calculé, dérivé de l'agrégation du champ montant (WRBTR ou DMBTR) de tous les postes de la table BSEG pour une écriture comptable donnée. Exemples 1500.0025000.75125.50 | |||
| Raison de l'annulation ReversalReason | Un code indiquant la raison pour laquelle une écriture comptable a été annulée. | ||
| Description Lorsqu'un document est annulé, SAP permet à l'utilisateur de spécifier un code motif. Ce code fournit des informations structurées sur la raison de l'annulation, par exemple, une date de comptabilisation incorrecte ou une erreur de saisie des données. Cet attribut est une donnée essentielle pour le tableau de bord 'Analyse des annulations d'écritures de journal'. En analysant les raisons d'annulation les plus fréquentes, les organisations peuvent identifier des problèmes systémiques dans leurs processus ou des lacunes en matière de formation, et prendre des mesures ciblées pour prévenir les erreurs futures et réduire le taux d'annulation. Pourquoi c'est important Offre un aperçu direct des raisons des annulations, permettant une analyse ciblée des causes profondes pour réduire les erreurs futures. Où obtenir Situé dans la table d'en-tête de document BKPF, champ STGRD. Exemples 010205 | |||
| Temps d'approbation ApprovalTime | Le temps écoulé entre la soumission d'une écriture comptable pour approbation et son approbation ou son rejet. | ||
| Description Cette métrique évalue la durée du sous-processus d'approbation, qui contribue souvent de manière significative au temps de cycle global. Elle est calculée comme la différence de temps entre l'activité 'Saisie de journal soumise' et l'activité correspondante 'Saisie de journal approuvée' ou 'Saisie de journal rejetée'. Le temps d'approbation est la métrique clé pour le tableau de bord 'Performance d'approbation des écritures de journal' et le KPI 'Temps moyen d'approbation des écritures de journal'. L'analyse de cette durée permet d'identifier les goulots d'étranglement dans le flux d'approbation, de mesurer la performance des approbateurs et de justifier des modifications de processus, comme l'ajustement des seuils d'approbation. Pourquoi c'est important Quantifie la durée de l'étape d'approbation, aidant à identifier et à résoudre les retards dans le workflow de révision et d'approbation. Où obtenir Calculé en soustrayant l'horodatage de l'événement 'Écriture comptable soumise' de l'événement 'Écriture comptable approuvée' ou 'Écriture comptable rejetée'. Exemples P1DT2HPT4H15MP3D | |||
| Temps de cycle CycleTime | Le temps total écoulé entre la création de la première activité d'écriture comptable et l'activité de comptabilisation finale. | ||
| Description Le temps de cycle est un indicateur clé de performance qui mesure la durée de bout en bout du processus d'écritures comptables. Il est calculé en prenant la différence entre l'horodatage de l'événement de comptabilisation finale et l'événement de création initiale pour une seule écriture comptable. Cette métrique calculée est la mesure principale sur le dashboard 'Temps de cycle de bout en bout des écritures comptables' et l'indicateur clé de performance (KPI) 'Temps de cycle moyen des écritures comptables'. Elle offre une vue d'ensemble de l'efficacité globale du processus et est utilisée pour suivre l'impact des initiatives d'amélioration au fil du temps. Pourquoi c'est important Mesure l'efficacité globale de bout en bout du processus, fournissant une métrique clé pour identifier les goulots d'étranglement et suivre les améliorations. Où obtenir Calculé en soustrayant l'horodatage du premier événement de l'horodatage du dernier événement pour chaque cas (JournalEntryId). Exemples P2DT3H15MPT8H30MP5D | |||
Activités Record to Report - Écritures comptables
| Activité | Description | ||
|---|---|---|---|
| Annulation d'écriture comptable traitée | Cette activité marque l'annulation d'une écriture comptable précédemment comptabilisée. Une annulation est un nouveau document comptable qui annule l'écriture originale. | ||
| Pourquoi c'est important C'est un événement critique pour mesurer la qualité des données et la précision des processus. Un taux élevé d'annulations indique des problèmes systémiques dans les étapes initiales de saisie de données ou d'approbation, et chaque annulation représente un retravail. Où obtenir Cet événement est identifié dans l'en-tête du document original (table BKPF). Lorsqu'un document est annulé, SAP renseigne le numéro du document d'annulation (BKPF-STBLG) et le motif d'annulation (BKPF-STGRD). L'horodatage de l'événement est la date de comptabilisation du nouveau document d'annulation. Capture Identifier quand BKPF-STBLG est renseigné sur le document original ; l'horodatage est la date de comptabilisation du document d'annulation. Type d'événement explicit | |||
| Écriture comptable approuvée | Cette activité marque l'approbation finale d'une écriture comptable au sein d'un workflow, la rendant éligible pour la comptabilisation. Cet événement est capturé à partir du journal du workflow lorsque l'étape finale de 'libération' ou d''approbation' est terminée. | ||
| Pourquoi c'est important C'est un jalon clé qui conclut le processus d'approbation. La durée menant à cette activité est un KPI critique pour l'efficacité de l'approbation, et le temps écoulé entre cet événement et la comptabilisation mesure le décalage post-approbation. Où obtenir Déduit de l'horodatage de l'achèvement de l'étape finale d'approbation dans le journal du workflow SAP Business. Il s'agit de la dernière action d'approbation avant que le document ne soit comptabilisé ou préparé pour la comptabilisation. Capture Identifier l'achèvement de l'étape finale de 'libération' ou d''approbation' dans les journaux de workflow. Type d'événement inferred | |||
| Écriture comptable comptabilisée | C'est l'activité centrale où l'écriture comptable est officiellement enregistrée dans le grand livre général, impactant les états financiers. Cet événement est capturé explicitement lorsque le statut du document est défini sur 'comptabilisé' et qu'une date de comptabilisation est attribuée. | ||
| Pourquoi c'est important C'est le jalon le plus important, signifiant le traitement réussi d'une écriture comptable. Le temps de cycle de bout en bout est souvent mesuré jusqu'à ce point, et c'est un événement clé pour l'analyse de la clôture financière. Où obtenir Identifié lorsqu'un document de la table BKPF a une date de comptabilisation (BKPF-BUDAT). Pour les documents pré-enregistrés, cela correspond au moment où le statut BKPF-BSTAT passe de 'V' à vide. L'horodatage de la comptabilisation est la date de saisie BKPF-CPUDT. Capture Identifier quand BKPF-BSTAT passe de 'V' à vide, ou pour les comptabilisations directes, l'événement de création. Type d'événement explicit | |||
| Écriture comptable pré-enregistrée | Cette activité marque la création initiale d'une écriture comptable dans un état préliminaire, avant qu'elle ne soit officiellement comptabilisée dans le grand livre général. Cela est capturé explicitement dans SAP lorsqu'un utilisateur sauvegarde un document à l'aide d'une transaction de pré-enregistrement, définissant le statut du document comme 'pré-enregistré'. | ||
| Pourquoi c'est important C'est un événement de démarrage critique pour les processus impliquant la révision et l'approbation. L'analyse du temps entre le pré-enregistrement et la comptabilisation aide à identifier les retards dans les phases de pré-comptabilisation et d'approbation. Où obtenir Cet événement est identifié à partir de la table d'en-tête de document BKPF. Un document est considéré comme pré-enregistré lorsqu'il est créé avec un statut BKPF-BSTAT = 'V'. L'horodatage de l'événement est la date et l'heure de création, BKPF-CPUDT et BKPF-CPUTM. Capture Identifier la création de document dans BKPF où BKPF-BSTAT est 'V'. Type d'événement explicit | |||
| Écriture comptable soumise | Cette activité signifie qu'une écriture comptable pré-enregistrée a été finalisée par son créateur et est maintenant prête pour la révision et l'approbation. Elle est généralement capturée par l'initiation d'une tâche du workflow SAP Business associée au document pré-enregistré. | ||
| Pourquoi c'est important Cela marque le transfert du créateur à l'approbateur, déclenchant le calcul des KPI de temps de cycle d'approbation. C'est un jalon clé pour mesurer l'efficacité du workflow d'approbation. Où obtenir Déduit de l'heure de début de l'instance de workflow d'approbation liée à l'objet document financier. Cela nécessite d'analyser les tables de journal du workflow comme SWW_WI2OBJ pour trouver le workflow démarré pour le code société, le numéro de document et l'année fiscale spécifiques. Capture Identifier l'événement de début du workflow pour l'objet document pré-enregistré. Type d'événement inferred | |||
| Comptabilisation inter-sociétés identifiée | Une activité calculée qui signale une écriture comptable affectant plus d'un code société. Ceci est déterminé par l'analyse des postes d'un même document financier. | ||
| Pourquoi c'est important Les transactions inter-sociétés peuvent avoir des exigences de traitement et d'approbation plus complexes. Les identifier permet une analyse distincte de leurs temps de cycle et de leurs chemins de processus pour trouver des goulots d'étranglement uniques. Où obtenir Calculé en examinant la table des postes BSEG pour un numéro de document donné (BELNR). Si les postes contiennent plus d'un code société distinct (BSEG-BUKRS), l'écriture est une comptabilisation inter-sociétés. Capture Vérifier si plusieurs valeurs uniques de Type d'événement calculated | |||
| Documentation jointe | Cette activité représente un utilisateur joignant des documents justificatifs, tels que des factures ou des feuilles de calcul, à l'écriture comptable. Cet événement n'est pas explicitement enregistré comme un événement comptable standard et est généralement déduit en vérifiant la création de pièces jointes liées à l'objet document comptable. | ||
| Pourquoi c'est important Le suivi de cette activité aide à vérifier la conformité aux politiques exigeant une documentation. Les retards dans l'attachement des documents peuvent être une cause profonde de cycles d'approbation prolongés. Où obtenir Il est difficile de capturer cet événement de manière fiable en tant qu'événement horodaté. Il peut potentiellement être déduit en analysant les tables de pièces jointes des Services d'Objets Génériques (GOS), telles que SOOD, et en liant l'horodatage de création de la pièce jointe à la clé de l'objet d'écriture comptable. Capture Déduire de l'horodatage de création des objets liés dans les tables GOS (ex: SOOD). Type d'événement inferred | |||
| Écriture comptable corrigée | Cette activité indique que le créateur original a modifié une écriture comptable pré-enregistrée après qu'elle ait été renvoyée pour modifications. Elle est déduite en détectant les modifications apportées au document après un événement 'Modifications demandées'. | ||
| Pourquoi c'est important Le suivi des corrections aide à quantifier l'effort consacré aux reprises. Le délai entre une demande de modification et la correction met en évidence les retards dans la résolution des problèmes liés aux écritures soumises. Où obtenir Déduit en analysant les journaux de modifications (tables CDHDR et CDPOS) pour le document pré-enregistré. Une modification enregistrée après un événement de rejet dans le workflow signifie qu'une correction a été effectuée. L'horodatage provient de la table CDHDR. Capture Identifier l'entrée du journal des modifications dans CDHDR/CDPOS après un événement de rejet. Type d'événement inferred | |||
| Écriture comptable pré-enregistrée supprimée | Représente la suppression d'une écriture comptable pré-enregistrée qui n'a jamais été comptabilisée. Cela peut se produire après un rejet ou si 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 pré-enregistrés sont supprimés peut révéler des problèmes tels que des écritures en double ou des incompréhensions du processus. Où obtenir Cet événement est capturé lorsque le statut d'un document pré-enregistré dans la table BKPF est modifié. Le champ de statut BKPF-BSTAT est mis à jour à 'Z' (Document pré-enregistré supprimé). L'horodatage de la modification se trouve dans les journaux de modifications de documents (CDHDR). Capture Identifier quand BKPF-BSTAT est mis à jour à 'Z'. Type d'événement explicit | |||
| Écriture comptable rejetée | Cette activité signifie le rejet final d'une écriture comptable, après quoi elle ne sera pas comptabilisée. Il s'agit généralement d'un statut terminal dans un workflow d'approbation, entraînant la suppression éventuelle du document pré-enregistré. | ||
| Pourquoi c'est important Le suivi des rejets est crucial pour la gestion de la qualité. L'analyse des raisons et de la fréquence des rejets contribue à améliorer le taux de conformité dès la première tentative pour les écritures de journal. Où obtenir C'est un résultat capturé à partir du journal du workflow SAP Business, représentant une décision utilisateur finale de 'rejet' qui met fin au processus. Le document pré-enregistré peut ensuite être supprimé. Capture Identifier le statut terminal de 'rejet' dans le journal de workflow du document. Type d'événement inferred | |||
| Écriture de journal créée | Représente la création d'une écriture comptable qui est comptabilisée directement, sans étape de pré-enregistrement préalable. Cela est capturé lorsqu'un document est créé dans SAP en utilisant une transaction de comptabilisation directe. | ||
| Pourquoi c'est important Cette activité sert de point de départ alternatif pour des processus d'écritures comptables plus simples qui ne nécessitent pas de workflow d'approbation. Elle aide à différencier les comptabilisations directes simples des écritures pré-enregistrées plus complexes. Où obtenir Cet événement correspond à la création d'un document dans la table BKPF où le statut du document BKPF-BSTAT est vide (comptabilisé). L'horodatage de l'événement est la date de création, BKPF-CPUDT. Pour ces documents, les événements 'Créé' et 'Comptabilisé' se produisent simultanément. Capture Identifier la création de document dans BKPF où BKPF-BSTAT est vide. Type d'événement explicit | |||
| Modifications d'écriture comptable demandées | Représente un point dans le workflow où un approbateur a examiné l'écriture comptable et l'a renvoyée au créateur pour correction. Cet événement est capturé à partir des journaux du workflow indiquant une décision utilisateur de 'rejet' ou de 'renvoi'. | ||
| Pourquoi c'est important Cette activité est essentielle pour identifier les boucles de retravail, qui sont une source principale d'inefficacité et de déviation des processus. Une fréquence élevée de cet événement indique des problèmes de qualité des écritures ou des exigences peu claires. Où obtenir Cet événement est déduit de l'horodatage d'une étape de décision utilisateur spécifique dans le journal du workflow SAP Business qui correspond à une action de 'rejet' ou de 'renvoi pour correction'. Capture Identifier l'horodatage de la décision de 'rejet' ou de 'retravail' dans les journaux du workflow. Type d'événement inferred | |||
| Poste d'écriture comptable apuré | Cette activité représente le lettrage d'un poste de compte général (G/L account) géré en partie ouverte, tel qu'un compte de virement bancaire. Elle se produit lorsqu'un poste est mis en correspondance avec un autre, le clôturant. | ||
| Pourquoi c'est important Pour les processus comme le rapprochement bancaire, le temps de compensation des éléments est un KPI crucial. Cette activité aide à analyser l'efficacité du rapprochement et des procédures de clôture de fin de mois. Où obtenir Cet événement est capturé à partir de la table des postes BSEG. Lorsqu'un poste est apuré, les champs date d'apurement (BSEG-AUGDT) et document d'apurement (BSEG-AUGBL) sont renseignés. L'horodatage de l'événement est la date d'apurement. Capture Identifier quand la date de compensation (BSEG-AUGDT) est renseignée pour un poste. Type d'événement explicit | |||
| Saisie manuelle identifiée | Cette activité identifie si une écriture comptable a été créée via une transaction manuelle en ligne ou via une interface automatisée ou un processus de lot. 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 Distinguer les écritures manuelles des écritures automatisées est essentiel pour une amélioration ciblée des processus. Les processus manuels sont souvent au centre des initiatives de standardisation et d'automatisation. Où obtenir C'est calculé en analysant les champs de la table d'en-tête de document BKPF. Les codes de transaction (BKPF-TCODE) comme 'FB01', 'FB50' ou 'FV50' indiquent une saisie manuelle, tandis que d'autres T-codes ou des noms d'entrée de lot spécifiques (BKPF-AWKEY) suggèrent l'automatisation. Capture Dériver de 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, et cliquez sur Créer. Donnez un titre approprié et définissez le type de programme sur 'Programme exécutable'.
- Définir l'écran de sélection : Dans le code source du programme, définissez l'écran de sélection. Cela permet aux utilisateurs de spécifier des paramètres comme une plage de dates pour la création de documents, les codes société et les types de documents pour limiter le volume de données à extraire.
- Déclarer les structures de données : Définissez une structure de table interne qui contiendra les données finales du journal d'événements. Cette structure doit inclure tous les champs requis : JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, et tous les attributs recommandés comme User, CompanyCode et PostingDate.
- Implémenter la logique de sélection des données : Rédigez les requêtes SQL ABAP principales pour extraire les données de chacune des 14 activités requises. Cela implique la sélection de données à partir de tables primaires comme BKPF (En-tête) et BSEG (Poste), des tables de journal des modifications CDHDR et CDPOS, des tables de workflow comme SWWLOGHIST, et des tables de compensation comme BSAS et BSAK.
- Extraire les documents mis en attente et comptabilisés : Pour les événements 'Écriture comptable mise en attente', sélectionnez dans BKPF où le statut du document (
BSTAT) est 'V'. Pour les événements 'Écriture comptable créée' et 'Écriture comptable comptabilisée', sélectionnez dans BKPF où le statut est vide, indiquant un document normal, 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 sur la clé du document pour trouver les modifications qui correspondent aux activités 'Écriture comptable corrigée' ou 'Écriture comptable mise en attente supprimée'.
- Extraire les événements de Workflow : Pour capturer des activités comme 'Écriture comptable soumise', 'Approuvée', 'Rejetée' et 'Modifications demandées', interrogez les tables de workflow. Utilisez la table SWW_WI2OBJ pour lier le document comptable à une instance de workflow, puis lisez SWWLOGHIST pour les décisions utilisateur spécifiques ou les changements de statut.
- Identifier les événements calculés : Pour 'Saisie manuelle identifiée', vérifiez le code de transaction (
BKPF-TCODE) par rapport à une liste de t-codes de saisie manuelle connus. Pour 'Comptabilisation inter-sociétés identifiée', analysez les postes de la table BSEG pour un document donné afin de voir si plusieurs codes société sont impliqués. - Consolider et transformer les données : À mesure que les données de chaque activité sont sélectionnées, transformez-les dans la structure finale du journal d'événements. Concaténez le code société, le numéro de document et l'exercice fiscal pour créer le JournalEntryId. Convertissez les dates et heures SAP en un seul horodatage EventTime. Ajoutez les résultats de chaque requête à la table interne finale.
- Implémenter l'exportation de fichier : Utilisez les instructions de gestion de fichiers ABAP, telles que OPEN DATASET, LOOP AT, TRANSFER et CLOSE DATASET, pour écrire la table interne consolidée dans un fichier CSV ou plat sur le répertoire du serveur d'applications SAP (visible via la transaction AL11).
- Planifier comme tâche de fond : Allez à la transaction SM36 (Définir une tâche de fond). Créez une nouvelle tâche, définissez une étape qui exécute votre programme ABAP et définissez un calendrier, par exemple, toutes les nuits ou toutes les semaines pendant les heures creuses, pour automatiser le processus d'extraction.
- Récupérer et formater le fichier : Utilisez la transaction CG3Y ou collaborez avec votre administrateur système pour télécharger le fichier généré du serveur d'applications vers votre machine locale. Assurez-vous que l'encodage et le format du fichier sont adaptés au téléchargement dans votre outil de Process Mining.
Configuration
- Plage de dates : Il est essentiel de définir une plage de dates pour gérer la performance. Utilisez la date de création du document (
BKPF-CPUDT) comme filtre principal. Pour une analyse initiale, une période de 3 à 6 mois est recommandée. Pour les tests, utilisez une plage de quelques jours connue pour contenir des données. - Filtre sur le code société : Filtrez toujours par code société (
BKPF-BUKRS). L'extraction de données pour tous les codes société à la fois peut être extrêmement gourmande en ressources. Commencez par un ou un petit groupe de codes société pertinents. - Filtre sur le type de document : Utilisez le filtre sur le type de document (
BKPF-BLART) pour affiner la portée aux types spécifiques d'écritures comptables, tels que 'SA' pour les documents de grand livre, si vous n'avez pas besoin d'analyser tous les types de documents. - ID des tâches de Workflow : La logique d'extraction des événements de workflow dépend des ID de tâches spécifiques utilisés dans votre système pour l'approbation, le rejet et la soumission. Ces ID doivent être configurés dans le code source du programme en fonction des définitions de workflow de votre entreprise.
- Considérations de performance : Le programme joint plusieurs grandes tables, notamment CDPOS et les tables d'historique de workflow. L'exécution pendant les heures de pointe peut avoir un impact sur les performances du système. Planifiez toujours son exécution en tâche de fond pendant les heures creuses. Envisagez de créer des index de base de données secondaires si la performance est un problème récurrent.
- Prérequis : Cette méthode nécessite un utilisateur disposant d'autorisations de développement ABAP (pour SE38) et de permissions pour créer et gérer des tâches de fond (pour SM36). L'utilisateur ou la tâche a également besoin d'un accès en lecture à toutes les tables financières, de workflow 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, vous devez configurer les espaces réservés dans la requête. Remplacez
'[START_DATE]'et'[END_DATE]'par la plage de dates souhaitée au format 'AAAAMMJJ'. Remplacez'[COMPANY_CODE_1]', '[COMPANY_CODE_2]'par les codes société SAP spécifiques que vous souhaitez analyser. - Définir le système source : Dans l'instruction
SELECTprincipale, remplacez l'espace réservé'[Your SAP System ID]'par l'ID réel du système SAP (SID) pour identifier correctement la source de données. - Exécuter la requête : Exécutez la requête SQL configurée sur la base de données SAP. Le temps d'exécution variera en fonction de la plage de dates et de la taille de vos tables de base de données.
- Examiner les résultats initiaux : Une fois la requête terminée, parcourez brièvement les lignes renvoyées pour vous assurer que les données sont remplies comme prévu. Vérifiez qu'il y a une variété d'activités et que les champs clés comme
JournalEntryIdetEventTimene sont pas vides. - Gérer les horodatages : La requête concatène les champs de date et d'heure en une chaîne
AAAAMMJJHHMMSS. Assurez-vous que votre système de post-traitement ou cible peut analyser ce format, ou ajustez la fonction SQLCONCATà un format ISO 8601 commeAAAA-MM-DDTHH:MM:SSsi votre base de données le prend en charge. - Exporter les données : Exportez l'ensemble complet des résultats de votre client SQL vers un fichier CSV. Assurez-vous d'utiliser l'encodage UTF-8 pour éviter les problèmes avec les caractères spéciaux.
- Préparer le téléchargement : Avant de télécharger vers un outil de Process Mining, confirmez que les en-têtes de colonnes correspondent au schéma de données requis.
JournalEntryId,ActivityNameetEventTimesont critiques. Ajoutez la colonneLastDataUpdate, en la renseignant avec l'horodatage de l'exécution de l'extraction. - Validation finale : Effectuez les étapes décrites dans la section 'validationSteps' pour vous assurer que les données extraites sont complètes et précises avant de commencer votre analyse.
Configuration
- Autorisations de base de données : L'utilisateur de la base de données requiert 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 aux équipes techniques spécialisées.
- Filtrage par plage de dates : Il est crucial de filtrer les données par une plage de dates spécifique pour garantir la performance des requêtes. La requête fournie utilise des espaces réservés pour une date de début et une date de fin, qui sont appliquées à la date de création du document (
BKPF.CPUDT). Une période de 3 à 6 mois est recommandée pour une analyse initiale. - Filtrage par entité : Pour gérer le volume des données et cibler l'analyse, filtrez toujours par Code Société (
BKPF.BUKRS). Vous pouvez également envisager de filtrer par Type de Document (BKPF.BLART) pour n'inclure que les types d'écritures comptables pertinents, par exemple 'SA' pour les documents de grand livre, et exclure les documents opérationnels comme les factures ou les paiements s'ils ne sont pas dans le périmètre. - Considérations de performance : Les requêtes directes sur des tables centrales comme BSEG et CDPOS peuvent être gourmandes en ressources. Il est fortement recommandé d'exécuter cette extraction pendant les heures creuses pour éviter d'impacter les performances du système pour les utilisateurs finaux. Évitez d'extraire des données pour plus d'un an en une seule exécution.
- ID 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]'. Ceux-ci doivent être remplacés par les ID de tâche réels de la configuration spécifique du workflow d'écritures comptables de votre système. Ils peuvent être identifiés en collaborant avec un spécialiste des workflows SAP 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
- Établir la connexion SAP : Dans votre outil ETL tiers, configurez une nouvelle connexion source à votre système SAP ECC. Cela nécessite généralement les détails du serveur d'applications, le client, le numéro de système et un utilisateur SAP dédié avec les autorisations RFC nécessaires.
- Définir les sources de données : Au sein de votre projet d'extraction, ajoutez les tables SAP requises comme sources de données. Les tables principales incluent BKPF (En-tête de document comptable), BSEG (Poste de document comptable), VBSEGK (En-tête de document mis en attente), CDHDR (En-tête de document de modification), CDPOS (Postes de document de modification), SWW_WI2OBJ (Liens Workflow vers Objet), SWWLOGHIST (Journal de Workflow) et SRGBTBREL (Relations pour les pièces jointes GOS).
- Extraire les événements de base (Créé et Mis en attente) : Créez le premier flux de données pour extraire les événements initiaux. Pour 'Écriture comptable mise en attente', utilisez VBSEGK comme source. Pour 'Écriture comptable créée', utilisez BKPF, en vous assurant de filtrer les documents qui ne sont pas des annulations et qui n'ont pas été initialement mis en attente. Cela peut être fait par une anti-jointure avec VBSEGK.
- Extraire les événements de Workflow : Créez un flux de données joignant BKPF à SWW_WI2OBJ en utilisant la clé d'objet (code société + numéro de document + exercice fiscal) pour trouver l'ID de l'instance de workflow. Joignez ce résultat avec SWWLOGHIST pour extraire des événements comme 'Soumis', 'Approuvé', 'Rejeté' et 'Modifications demandées' basés sur les résultats de la tâche de workflow et les décisions utilisateur enregistrées dans le journal.
- Extraire les événements de modification et de suppression : Utilisez les tables CDHDR et CDPOS pour identifier les modifications. Pour 'Écriture comptable corrigée', filtrez les modifications apportées aux documents mis en attente (Classe d'objet 'FIPP'). Pour 'Écriture comptable mise en attente supprimée', recherchez les marqueurs de suppression dans les journaux de modifications pour les documents mis en attente.
- Extraire les événements de pièce jointe : Pour capturer 'Documentation jointe', joignez BKPF à SRGBTBREL où le type d'objet est 'BKPF' et la relation est '[Votre type de relation de pièce jointe]'. La date de création du lien sert d'heure d'événement.
- Extraire les événements de compensation et d'annulation : Pour 'Poste d'écriture comptable compensé', interrogez la table BSEG où le champ de document de compensation (AUGBL) est renseigné. L'heure de l'événement est la date de comptabilisation du document de compensation (AUGDT). Pour 'Annulation d'écriture comptable traitée', interrogez BKPF pour les documents qui sont des annulations, identifiés par une valeur dans le champ de document annulé (STBLG).
- Dériver les événements calculés : Créez des blocs de logique distincts pour les événements calculés. Pour 'Saisie manuelle identifiée', filtrez BKPF sur la base d'une liste de codes de transaction manuels (par exemple, FB01, FB50, F-02). Pour 'Comptabilisation inter-sociétés identifiée', regroupez la table BSEG par ID de document et identifiez les documents avec plus d'un code société distinct.
- Combiner tous les flux d'événements : Utilisez une transformation UNION dans votre outil ETL pour fusionner les sorties de tous les flux d'événements individuels (Créé, Mis en attente, Approuvé, etc.) dans une seule table de journal d'événements. Assurez-vous que les noms de colonnes et les types de données sont cohérents dans tous les flux.
- Mapper au schéma final : Mappez les données combinées à la structure de journal d'événements requise, en créant
JournalEntryId,ActivityName,EventTime,User, et les autres attributs requis et recommandés. Ajoutez des colonnes statiques commeSourceSystemet utilisez l'heure d'exécution de la tâche ETL pourLastDataUpdate. - Configurer le chargement incrémental : Pour les extractions continues, configurez une stratégie de chargement incrémental. Utilisez la dernière date de création ou de modification (par exemple, BKPF.CPUDT, CDHDR.UDATE) comme marqueur pour ne récupérer que les enregistrements nouveaux ou mis à jour depuis la dernière exécution.
- Export for ProcessMind: Schedule the extraction job and configure the final output step to save the event log as a CSV or Parquet file in a location accessible by ProcessMind for upload.
Configuration
- Prérequis : Un outil ETL tiers sous licence (par exemple, Theobald Xtract Universal, Informatica, Talend) avec un connecteur SAP dédié. Un compte utilisateur SAP avec accès RFC et autorisations de lecture des tables financières (par exemple, S_TABU_DIS pour les groupes de tables F_00, F_WF), des données de workflow 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 de système et de l'ID client. Une gestion sécurisée des identifiants doit être utilisée pour le nom d'utilisateur et le mot de passe SAP.
- Filtres clés : Appliquez toujours des filtres sur le Code Société (
BKPF.BUKRS) et l'Exercice (BKPF.GJAHR) à la source pour limiter le volume de données. Il est fortement recommandé de filtrer sur la Date de Création du Document (BKPF.CPUDT) pour définir une période d'extraction spécifique, par exemple les 6 derniers mois. - Sélection de la plage de dates : Pour le chargement initial, sélectionnez une période représentative, par exemple de 3 à 6 mois. Pour les chargements delta ultérieurs, utilisez un marqueur sur un champ d'horodatage comme
CPUDTpour ne récupérer que les nouveaux enregistrements. - Considérations de performance : Les jointures sur les tables BSEG, CDPOS et de workflow peuvent être très lentes. Assurez-vous que votre outil ETL transmet les filtres à la source SAP lorsque cela est possible. Extrayez les données par petits blocs ou paquets si l'outil le permet, surtout pour les chargements historiques importants.
- Personnalisation du Workflow : La logique pour identifier les activités de workflow comme 'Approuvé' ou 'Rejeté' dépend fortement de vos modèles de workflow spécifiques. Vous devrez identifier les ID de tâches de workflow et les clés de décision utilisateur corrects de votre système pour les utiliser dans les filtres.
a Exemple de requête config
/*
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